REST API Reference
Note: This REST API reference is primarily intended for:
Python backend developers (no SDK available for Python)
Debugging and troubleshooting (understanding what the SDK does under the hood)
Advanced use cases requiring direct server communication
Java backend developers should use the Arculus SDK server-side methods (
ArculusFidoServer.callRegisterBegin(),callRegisterComplete(), etc.) instead of direct REST API calls. The SDK abstracts these endpoints and provides better error handling, session management, and future compatibility.
This document provides the complete API reference for the Arculus FIDO2 Server authentication endpoints.
Base URL
https://your-arculus-fido2-server.comNote: All FIDO2 API endpoints are prefixed with /fidoapi/. The base URL should not include /api in the path.
Authentication Flow Overview
The FIDO2 authentication process consists of two main flows:
Registration (Attestation): Creating a new credential
Authentication (Assertion): Verifying an existing credential
Each flow requires two API calls: begin and complete.
Registration: attestation/options -> attestation/result
Authentication: assertion/options -> assertion/resultEndpoints
Registration Endpoints
POST /fidoapi/certify/attestation/options
Begin FIDO2 Registration. This endpoint initiates the credential creation process.
Alias: POST /fidoapi/register/begin
Request Body
username
string
Yes
Unique identifier for the user
displayName
string
Yes
Human-readable name for display
userVerification
string
No
preferred, required, or discouraged
attestation
string
No
none, direct, or indirect
attachment
string
No
platform, cross-platform, or all
algorithms
array
No
Array of algorithm strings (e.g., ["es256", "rs256"])
discoverable_credential
string
No
preferred, required, or discouraged
authenticatorSelection
object
No
Authenticator selection criteria (see below)
keypair
object
No
Optional device metadata
authenticatorSelection object (optional):
requireResidentKey
boolean
If true, sets residentKey to "preferred" in response
userVerification
string
Override user verification requirement
Example Request
Success Response (200)
POST /fidoapi/certify/attestation/result
Finalize FIDO2 Registration. This endpoint completes credential creation after the authenticator response.
Alias: POST /fidoapi/register/complete
Request Body
type
string
Yes
Must be public-key
id
string
Yes
Base64URL-encoded credential ID
rawId
string
Yes
Base64URL-encoded raw credential ID
authenticatorAttachment
string
No
platform or cross-platform
response
object
Yes
Authenticator response object
response.clientDataJSON
string
Yes
Base64URL-encoded client data
response.attestationObject
string
Yes
Base64URL-encoded attestation
response.transports
array
No
Array of transport strings
clientExtensionResults
object
No
Extension results
Example Request
Success Response (200)
Authentication Endpoints
POST /fidoapi/certify/assertion/options
Begin FIDO2 Assertion. This endpoint initiates the authentication process.
Alias: POST /fidoapi/authenticate/begin
Request Body
username
string
Yes
Username to authenticate
userVerification
string
No
preferred, required, or discouraged
Example Request
Success Response (200)
POST /fidoapi/certify/assertion/result
Complete FIDO2 Assertion. This endpoint verifies the authenticator signature.
Alias: POST /fidoapi/authenticate/complete
Request Body
type
string
Yes
Must be public-key
id
string
Yes
Base64URL-encoded credential ID
rawId
string
Yes
Base64URL-encoded raw credential ID
authenticatorAttachment
string
No
platform or cross-platform
response
object
Yes
Authenticator response object
response.clientDataJSON
string
Yes
Base64URL-encoded client data
response.authenticatorData
string
Yes
Base64URL-encoded authenticator data
response.signature
string
Yes
Base64URL-encoded signature
response.userHandle
string
No
Base64URL-encoded user handle
Example Request
Success Response (200)
Test Endpoints
GET /fidoapi/test
Test if the FIDO API is available and correctly configured.
Response
GET /fidoapi/testmongo
Test if MongoDB connection is available.
Response
Administrative Endpoints
GET /status
Health check and status dashboard.
Response: HTML status page
GET /getversion
Returns server version information.
Response: HTML page with version details
GET / (Root)
Server main dashboard (requires authentication).
Response: HTML dashboard page
User Management API
The User API (/userapi/*) is protected by Basic Authentication by default.
Default credentials (configurable via server options):
Username:
redpathPassword:
password
To disable authentication, start the server with --auth off.
GET /userapi
User management dashboard.
Response: HTML dashboard page
GET /userapi/manageusers
User administration endpoint with query parameters.
Query Parameters
filter
string
Filter users (supports wildcards, e.g., fil*)
device
string
Device name filter
type
string
Operation type (see below)
Type Values
list
List users matching filter
deluser
Delete user
deldevice
Delete specific device
disableall
Disable all credentials for user
enableall
Enable all credentials for user
disabledevice
Disable specific device
enabledevice
Enable specific device
Example Requests
Example Response (list)
GET /userapi/aaguid
Get the AAGUID whitelist.
Response
Note: The AAGUID filtering feature must be enabled with --aaguid on.
GET /userapi/invoice
Generate invoice data for billing.
Query Parameters
date
string
Date in YYYY-MM-DD format (default: today)
invoicelog
string
Set to yes to log the invoice
Example Requests
Response
GET /userapi/invoiceest
Estimate invoice generation time.
Response
POST /userapi/upload
Upload a list of users to query.
Request: multipart/form-data with file
Response
GET /userapi/deletelistusers
Delete users from an uploaded list (dashboard page).
Response: HTML interface for bulk user deletion
Request Headers
All API requests should include:
Multi-Tenant Support
For multi-tenant deployments, specify the relying party using the X-ArculusFido-RelyingParty header:
Note: The header value should be a domain name (e.g., example.com), not a full URL. The server will extract the hostname if a full URL is provided.
Session Management
Important: Session cookies are critical for FIDO2 operations. The registration and authentication flows use session cookies to maintain state between the begin and complete endpoints.
Without proper cookie handling:
The "complete" call cannot find the challenge from the "begin" call
You will receive "Session expired" (E0024R) errors
The authentication or registration flow will fail
Ensure your client:
Stores cookies from the "begin" response (check
Set-Cookieheader or enable automatic cookie handling)Sends cookies with the "complete" request (include
Cookieheader or usecredentials: 'include'in fetch)
Session cookies are required for the complete endpoints to validate the challenge and user context from the corresponding begin request. For more details, see Session Cookie Management in the Authenticator Lifecycle documentation.
Error Responses
All endpoints return consistent error responses. For detailed error codes and handling, see 2.7 Error Codes Reference.
Error Response Format:
Note: The status field may be "failed" or "false" depending on the error type. Session-related errors typically return "status": "false".
CORS Support
The server supports Cross-Origin Resource Sharing (CORS). Ensure your client includes:
This is required for session cookie management during the registration and authentication flows.
Data Format Reference
Base64URL Encoding
All binary data in the API uses Base64URL encoding (RFC 4648):
Standard Base64 with
-instead of+Standard Base64 with
_instead of/No padding characters (
=)
Example Encoding:
COSE Algorithm Identifiers
Public key credential parameters use COSE algorithm identifiers:
ES256
-7
ECDSA with SHA-256
RS256
-257
RSASSA-PKCS1-v1_5 with SHA-256
EdDSA
-8
Edwards-curve Digital Signature
Reference: IANA COSE Algorithm Registry
AAGUID Format
The Authenticator Attestation GUID (AAGUID) is a 16-byte identifier for authenticator models.
Format: UUID string with hyphens
Example:
A null AAGUID (all zeros) indicates the authenticator does not provide model identification:
Credential Protection Levels
The credProtect extension provides additional credential security:
0
User Verification Optional
Credentials usable without verification; may be discoverable
1
UV Optional, Non-Discoverable
No verification required; credential not enumerable
2
User Verification Required
Verification required; credential protected
3
High Protection
Maximum security; additional restrictions apply
Last updated

