Federated JWT Security and JWKS Verification

Overview#

Argus federated JWT security signs every platform authentication token with asymmetric RS256 cryptography and distributes public verification keys through a standards-compliant JWKS (JSON Web Key Set) endpoint, so federated partners and internal services verify tokens without ever holding a shared secret.

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.

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. The same rigour applies to machine-to-machine and edge token verification: tokens are structurally validated before any cryptographic work begins, audience and issuer checks fail closed, and stale key material is never trusted.

Key Features#

• RS256-Only Token Signing: All JWT tokens are signed exclusively with RSA-SHA256 using strong asymmetric keys with an enforced minimum size. HS256 and other symmetric algorithms are permanently disabled to prevent downgrade attacks, and legacy shared-key headers for internal service calls are refused outright in production.
• JWKS Public Endpoint: A standards-compliant well-known JWKS endpoint 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.
• Structural Pre-Verification: Service credentials are checked for correct structure and token type before any expensive processing. Tokens missing the required type marker are rejected, and malformed or hostile permission claims produce a clean authentication failure rather than a server error.
• Fail-Closed Audience and Issuer Checks: Verification refuses every token when no audience allowlist is configured, so nothing is accepted by accident of library defaults. Edge access tokens are verified for issuer and required expiry, and matched to the correct published signing key.
• Bounded Key Cache Staleness: Cached signing-key material from the JWKS endpoint is subject to a hard staleness cap; once the cap is exceeded, verification fails closed rather than trusting outdated keys.
• Issuance Flood Protection: Structural pre-checks and a concurrency cap on the credential issuance endpoint prevent unauthenticated request floods from exhausting resources, including during service cold starts.
• Exact Permission Scope Matching: Service-to-service permission scopes match on whole path segments, eliminating prefix-confusion grants where access to one resource could silently extend to another with a similar name.
• Asymmetric Share Tokens: Share tokens, including secure video-share links, are signed with the same RS256 asymmetric scheme; symmetric fallbacks are locked out and enforced by automated tests.
• 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.
• Multi-National Federation: The token architecture supports federated authentication across multi-national deployments, with every participating nation able to verify tokens independently using published key material.
• 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 programmatic 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.
• Penetration Testing: Security teams probing token forgery, stale key acceptance, and audience confusion encounter fail-closed behaviour at every verification step, with hostile inputs rejected cleanly rather than triggering server errors.
• Denial-of-Service Resilience: Platform operators depend on issuance flood protection to keep the credential issuer responsive when unauthenticated request surges arrive during service cold starts.

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. Edge services and machine-to-machine callers verify tokens against the same published key material, governed by the bounded cache staleness and fail-closed audience rules.

Open Standards#

• RFC 7519 (JSON Web Token): All platform authentication tokens are structured as JWTs, with issuer, audience, and expiry claims 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 the well-known JWKS location, allowing federated participants and third-party services to retrieve and cache RSA public keys, identified by their key identifier, for 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 follows the BCP guidance: verification keys are selected by their published key identifier, revocation checking fails closed, symmetric algorithms are rejected outright, and audience checks refuse tokens when no allowlist is configured.
• 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 Bearer authorisation header, 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 path, conforming to the well-known URI framework to ensure federated consumers can locate key material by convention.
• FIPS 140-2: RSA key generation and key storage are designed to align with FIPS 140-2 guidance for cryptographic modules, and hardware-backed key storage can be used in environments that require hardware-validated key protection.

Last Reviewed: 2026-07-16 Last Updated: 2026-07-16