System Architecture

The Arculus Authentication system follows a layered architecture that separates client applications, backend infrastructure, and data persistence. At the client layer, mobile applications (iOS and Android) integrate the Arculus FIDO2 SDK to handle NFC/CTAP2 communication with Arculus hardware security keys. Desktop applications can use the Java SDK to interact with FIDO2 cards via NFC readers, while web applications can use browser-based WebAuthn APIs (with optional JavaScript SDK support) to interact with FIDO2 authenticators. These client applications communicate with backend services through a load balancer, which provides SSL/TLS termination and routes requests to the appropriate services.

Client Layer

Client Applications

Client applications (mobile iOS/Android apps, desktop applications, and web applications) provide the user interface and interact with the Arculus FIDO2 card via NFC. They integrate the Arculus FIDO2 SDK to handle card operations (registration, authentication, PIN management) and communicate with backend services or the FIDO2 server directly. Client applications do not store FIDO2 credentials; credentials are stored on the Arculus card and in the FIDO2 server.

Various SDKs abstracts the complexity of NFC communication and CTAP2 protocol handling for mobile and desktop applications, allowing developers to implement FIDO2 authentication with simple API calls. Web applications can leverage browser WebAuthn APIs directly or use the JavaScript SDK wrapper. The architecture supports both client-direct deployments (where applications communicate directly with FIDO2 servers) and backend-proxied deployments (where backend services proxy FIDO2 communication), providing flexibility to meet different security and network requirements.

Mobile SDKs

Native SDKs used for mobile application integration.

iOS SDK:

• Swift Package (xcframework)

• NFC-based authenticator communication

• Sample applications included

Android SDK:

• AAR library

• NFC and USB transport support

• Sample applications included

Desktop SDK (Java)

The Desktop SDK is a Java library for desktop application integration. Used for desktop applications that need direct hardware access to NFC readers for FIDO2 card operations.

• NFC reader communication (PC/SC)

• FIDO2/CTAP2 protocol support

• Hardware authenticator management

• Cross-platform support (Windows, macOS, Linux)

Web SDK (arculusfido.js)

JavaScript library for web application integration using browser WebAuthn APIs. Used when creating web applications that can leverage browser WebAuthn APIs for FIDO2 authentication without requiring desktop application components.

• Browser WebAuthn API wrapper

• Simplified registration and authentication flows

• Configurable FIDO policies

• Cross-origin support

Note: Example implementations demonstrate desktop application integration using the Java SDK. Web browser-based integration using WebAuthn APIs is also supported and can be implemented using the JavaScript SDK.

Arculus FIDO2 Card

Hardware security key that stores FIDO2 credentials in a secure element. The Arculus card communicates with client applications via NFC (ISO 14443) and requires user verification via PIN for all operations. The card is FIDO2 L1+ certified and provides tamper-resistant credential storage. The card does not communicate directly with servers; all server communication is handled by client applications or backend services.

Specifications:

• NFC communication (ISO 14443)

• FIDO2 L1+ certified

• Secure element for key storage

• User verification via PIN

Identity Provider

IAM System (OAuth2/OIDC Provider)

The Identity Access Management provider handles primary user authentication and authorization. This provider may be external (e.g., Auth0, Keycloak, Google, AzureAD) or internal (e.g., customer's own IAM system). The IAM provides OAuth2/OIDC authentication flows for initial user login before FIDO2 authentication. The IAM system handles user identity management but does not handle FIDO2 credential operations; those are managed by the PyFIDO Server.

Cloud Infrastructure

Load Balancer

This is the entry point to the customer's infrastructure that provides SSL/TLS termination, traffic routing, and load distribution. Routes client requests to either the PyFIDO Server (client-direct deployment) or Customer Backend Services (backend-proxied deployment).

Customer Backend Services

Customer's application backend services deployed in a servlet container (e.g., Tomcat). Handle application-specific business logic, user session management, and optionally proxy FIDO2 requests to the PyFIDO Server in backend-proxied deployments. Customer backend services are customer-developed and deployed; they are not provided by Arculus. They may integrate with the IAM system for user authentication and with the PyFIDO Server for FIDO2 operations.

PyFIDO Server

Core FIDO2 authentication engine that handles all FIDO2/WebAuthn protocol operations including credential registration, authentication challenges, attestation verification, and credential storage. Implements FIDO2 specification compliance and manages FIDO2 credentials in the database. The PyFIDO Server does not handle user authentication (username/password); that is handled by the IAM system. It only manages FIDO2 credential operations.

The core FIDO2 authentication engine is built with Python and Flask.

• FIDO2/WebAuthn compliance

• Multi-tenant support

• FIDO Metadata Service (MDS) integration

• JWT token generation

• Configurable attestation verification

Technology Stack:

• Python 3.12

• Flask web framework

• Waitress/Hypercorn WSGI servers

• MongoDB for credential storage

• Cryptographic libraries (PyCryptodome, PyASN1)

Default Port: 5001

Data Layer

MongoDB / Document Database

Persistent storage for FIDO2 credentials, user data, and tenant configuration. Stores credential public keys, credential metadata, and user-to-credential mappings. The database does not store private keys; private keys remain in the Arculus card's secure element. The database only stores public keys and metadata required for FIDO2 authentication.

Secrets Management Service

Secure storage for sensitive configuration data such as database connection credentials, API keys, and encryption keys. Provides encrypted storage and access control for secrets used by the PyFIDO Server and other services. The secrets management service does not store FIDO2 credentials; it only stores operational secrets needed for service configuration and database access.