Overview#
Allied nations running joint operations should not need to share secret keys to verify each other's authentication tokens. Neither should the dozens of internal services in a zero-trust microservice architecture. The moment you share a symmetric secret for token verification, every system that holds that secret becomes a potential point of compromise.
Argus enforces RS256 asymmetric cryptographic signing for all platform authentication tokens, with public key distribution through a standards-compliant JWKS (JSON Web Key Set) endpoint. Any participating system can validate tokens using publicly available key material, with no bilateral key exchange required. The module permanently disables symmetric HS256 signing, closing the downgrade attack surface entirely. JWT-based authentication supports auto-refresh with rotating refresh tokens, ensuring active sessions stay alive without forcing re-authentication while keeping each token's validity window short.
Key Features#
- RS256-Only Token Signing: All JWT tokens are signed exclusively with RSA-SHA256 using 2048-bit or larger keys. HS256 and other symmetric algorithms are permanently disabled to prevent downgrade attacks.
- JWKS Public Endpoint: A standards-compliant
/.well-known/jwks.jsonendpoint publishes current and rotated public keys, enabling any federated participant to verify tokens without prior key exchange. - Key Rotation with Auto-Refresh: Automated key rotation with configurable rotation periods, grace periods for in-flight tokens signed with previous keys, and key identifier (kid) tracking for seamless transitions. JWT access tokens are automatically refreshed before expiry using rotating refresh tokens.
- Fail-Closed Token Revocation: Token revocation checks default to denying access when the revocation service is unavailable, preventing authentication bypass during system disruptions.
- Multi-Tenant Key Isolation: Each tenant operates with independent signing keys, preventing token forgery across tenant boundaries even if a single tenant's infrastructure is compromised.
- EU Regulations Compliance: Token architecture meets EU Regulations requirements for federated authentication across multi-national deployments, supporting independent verification by all participating nations.
- Token Introspection: A standards-compliant token introspection endpoint serves systems that require real-time token validity checking beyond signature verification.
- Audit Trail: All token issuance, verification, revocation, and key rotation events are logged with full context for security audit and incident investigation.
Use Cases#
- Multi-National Operations: Allied nations deploy independent Argus instances that accept each other's authentication tokens through JWKS-based verification, enabling single sign-on across national boundaries without shared secrets.
- Microservice Architecture: Internal platform services verify authentication tokens using the JWKS endpoint without requiring access to signing keys, enabling zero-trust service-to-service authentication.
- Third-Party Integration: External systems validate Argus-issued tokens to authorise API access, using the public JWKS endpoint for key material without requiring bilateral credential sharing.
- Compliance Auditing: Security auditors verify that all authentication tokens use approved cryptographic algorithms and key strengths by inspecting the JWKS endpoint and token headers.
Integration#
The module is embedded in the authentication service and consumed by all platform components for token verification. It connects to the secrets management system for private key storage, the audit logging platform for authentication event recording, and the compliance dashboard for cryptographic compliance monitoring. The JWKS endpoint is publicly accessible for federated verification by external systems.
Open Standards#
- RFC 7519 (JSON Web Token): All platform authentication tokens are structured as JWTs with mandatory claims (
iss,sub,aud,exp,iat,nbf,jti) enforced at verification time, enabling any standards-compliant verifier to parse and validate tokens without proprietary tooling. - RFC 7517 (JSON Web Key): Public signing keys are published as a JWK Set document at
/.well-known/jwks.json, allowing federated participants and third-party services to retrieve and cache RSA public keys identified bykidfor token verification without bilateral key exchange. - RFC 7518 (JSON Web Algorithms): RS256 (RSASSA-PKCS1-v1_5 with SHA-256) is enforced as the sole permitted signing algorithm; all symmetric algorithms including HS256 are permanently disabled, closing the algorithm-confusion and downgrade attack surface.
- RFC 8725 (JSON Web Token Best Current Practices): Token validation enforces the BCP guidance by requiring
kid-based key selection, mandatoryjtiuniqueness, fail-closed revocation checking, and rejection of tokens lacking algorithm constraints. - RFC 7662 (OAuth 2.0 Token Introspection): A standards-compliant introspection endpoint allows resource servers and relying parties to query real-time token validity, active status, and claims beyond offline signature verification.
- RFC 6750 (OAuth 2.0 Bearer Token Usage): Tokens are transmitted to resource servers via the
Authorization: Bearerheader, with all platform components and middleware enforcing this transport convention consistently. - RFC 8615 (Well-Known Uniform Resource Identifiers): The JWKS public key document is served at the
/.well-known/jwks.jsonpath, conforming to the well-known URI framework to ensure federated consumers can locate key material by convention. - FIPS 140-2: Cryptographic operations including RSA key generation and storage are implemented against FIPS 140-2 requirements, with HSM-backed key storage available for classified environments requiring hardware-validated key protection.
Availability#
- Enterprise Plan: Full federated JWT security included
- Professional Plan: RS256 token signing included; federated JWKS and multi-tenant key isolation available as add-on
Last Reviewed: 2026-03-02 Last Updated: 2026-04-14