Development Options (Security)
This document describes the two primary development workflows for integrating Arculus Authenticate into your application. The choice between these approaches has significant security implications and must be decided before development begins.
Client-direct: Clients communicate directly with the FIDO2 server
Backend-proxied: Clients communicate through customer backend services
The choice of approach affects security, architecture, API usage, and development workflow. For the most secure implementation do not make your FIDO2 server accessible from the Internet. Giving clients direct access to the FIDO2 server (even through a proxy) exposes that service to more risk than if communication was abstracted through the backend services. In addition, your solution may want to:
centralize logging and audit trails
improve security with server-side validation
allow additional business logic before/after FIDO2 operations
The tradeoff is additional complexity (3 phases instead of direct calls).
Client-Direct Approach
In a client-direct approach, client applications communicate directly with the FIDO2 server through the load balancer (proxy).
Architecture
Client Application → Load Balancer → PyFIDO ServerIn the System Architecture diagram, this is represented as a dashed line from the Load Balancer to the PyFIDO Server (an optional path).
Characteristics
Direct Communication: Client applications have direct line-of-sight to the FIDO2 server
Simpler Architecture: Fewer components in the communication path
Client-Side SDK: Mobile and desktop applications use the Arculus FIDO2 SDK directly
Web Applications: Browser-based applications use WebAuthn APIs with optional JavaScript SDK
Security Considerations
FIDO2 server endpoints are exposed to client applications
Requires careful network security and access control
Load balancer must handle SSL/TLS termination and routing
Suitable for trusted client environments
Backend-Proxied Approach
In a backend-proxied approach, clients communicate with customer backend services (deployed in a servlet container) through the load balancer. The backend services act as a proxy for all FIDO2 requests to the PyFIDO Server.
Architecture
Characteristics
No Direct Access: Client applications have no line-of-sight to the FIDO2 server
Backend Proxy: Customer backend services handle both application logic and FIDO2 request proxying
Enhanced Security: FIDO2 server is protected behind backend services
Centralized Control: All FIDO2 operations flow through customer-controlled backend
Security Benefits
Greater Protection: No direct exposure of FIDO2 server to client applications
Sensitive Data Protection: FIDO2 server and sensitive data are isolated from clients
Centralized Security: Security policies and access control managed at backend layer
Audit Trail: All FIDO2 operations can be logged and monitored at the backend
Comparison
Architecture Complexity
Simpler
More complex
Security
Moderate
Enhanced
FIDO2 Server Exposure
Direct to clients
Behind backend
Development Workflow
Direct SDK usage
Backend proxy required
API Usage
Direct FIDO2 API calls
Backend API abstraction
Use Case
Trusted client environments
Enterprise, high-security
Decision Criteria
Choose Client-Direct if:
Client applications are trusted and controlled
Simpler architecture is preferred
Direct FIDO2 API access is acceptable
Network security can be managed at load balancer level
Choose Backend-Proxied if:
Enhanced security is required
FIDO2 server should be isolated from clients
FIDO2 server should not be directly accessible from the internet
Centralized control and monitoring are needed
You want centralized logging and audit trails
Enterprise or high-security deployments
You need to add business logic before/after FIDO2 operations
Your security requirements mandate server-side validation
Last updated