Security posture

A security reviewer evaluating an identity-resilience design asks two questions before the others. First: what does the platform issue during degraded state, who authorized its issuance, and how is its provenance traceable? Second: when a user should no longer be able to authenticate, how fast does that take effect, and what is the worst-case window in which the user could still get through? This page answers both, and surrounds them with the cryptographic, audit, and key-management properties that make the answers defensible.

Token issuance authority

Authonomy issues authentication artifacts to applications; the external identity providers do not issue directly to applications. This matters for failover behavior. When the router selects a fallback method — a secondary identity provider, or the native floor — the application receives the same shape of authentication artifact it received in normal operation. The claim set internally records which method served the authentication, so a downstream system can distinguish a primary-served token from a fallback-served token if its policy depends on that distinction.

Two properties follow:

Applications do not need fallback awareness. An application integrated against Authonomy consumes one token shape. It does not branch on “which identity provider issued this token” because, from its perspective, Authonomy issued it. This is the architectural property that makes fallback transparent to the application, and it’s what lets a security reviewer evaluate a single trust path between the application and Authonomy rather than a separate trust path per upstream method.

The issuance record is unified. Every token issuance — regardless of which method served the authentication — is recorded in the audit trail as a single event shape.

Token validation at the edge

Bearer-token validation at application edges is stateless. Applications validate tokens against cached JWKS retrieved from Authonomy’s issuer endpoint; the validation does not require a live call to Authonomy per request. This is the property that prevents an outage of Authonomy’s session/state store from cascading into an application authentication outage for traffic already authenticated: validation of an unexpired token does not depend on the store.

Refresh-token flows are stateful and do depend on the session/state store. A refresh-token request during a database outage at the affected instance fails until the database returns; the application’s in-flight tokens remain valid for their lifetime. This is the deliberate placement of statefulness in the architecture: the stateless path (bearer validation) is resilient to database failure; the stateful path (refresh, multi-step flow completion) is not.

Revocation under normal operation

An administrator disabling a user at the authoritative identity provider propagates to every Authonomy instance’s canonical view within the drift window. Once propagated, subsequent authentication attempts fail at every rung of the ladder.

The credential store carries the parallel revocation surface for Authonomy-native credential material: an operator revoking a credential — a lost WebAuthn key, a compromised password, a reported phishing event — propagates to every applicable instance within the drift and propagation window, after which the named credential is unusable everywhere.

In-flight sessions (tokens already issued) are not invalidated by either lifecycle or credential-revocation events themselves. Invalidation of in-flight sessions is a separate action: either an explicit session-invalidation at the session/state store (immediate effect for refresh-dependent sessions), or waiting for the token’s expiration. This separation is standard OIDC practice; it’s stated here because it’s the question a reviewer will ask.

Revocation when an instance is severed

A revocation issued at the authoritative source while an instance’s WAN to that source is severed does not reach the instance until reconnect. The same applies to credential revocations issued at the credential store.

During the severance, a user whose lifecycle has been deprovisioned upstream, or whose credential has been revoked in the credential store, can continue to authenticate at the severed instance if the credential material is still available there. This is the most important operational-risk statement in the design. It is named explicitly because every other resiliency decision sits on top of it.

Deployments whose threat model cannot tolerate a full-severance-duration lag on revocation have three levers:

• Reduce the drift window (faster pre-severance propagation, accepting higher sync traffic).
• Reduce the severance tolerance (shorter time before a severed instance degrades to refusing authentication).
• Restrict native credential enrollment to populations whose revocation lag is acceptable.

Each lever is a policy choice against the deployment’s risk posture. The platform supports the range; the deployment selects.

Operator-initiated emergency revocation

Two surfaces exist for revocations that need to propagate faster than the incremental cadence:

Targeted sync. Forces a specific revocation to propagate to an instance’s canonical view on demand: identity-lifecycle revocation through the identity stream, or native-credential revocation when the credential store is reachable. Audited and tenant-scoped.

Instance-level suspend. Directs an instance to stop serving authentication for a named user or population independently of the sync path. Useful when the targeted-sync route is unavailable (the credential store is severed, the upstream IdP is unreachable) but the operator needs to ensure the named subject cannot authenticate at that instance.

Both surfaces are written to the audit trail with the operator’s identity and the reason given.

Key management

Two classes of key material sit in the deployment, each with a distinct scope and lifecycle.

Token-signing keys at each instance. Each Authonomy instance holds its own signing key for the tokens it issues. Key rotation follows a published schedule; the instance’s JWKS includes the rotated key ahead of the transition so applications caching JWKS pick up the new key before the old key is retired. Multi-instance deployments expose each instance’s JWKS at that instance’s issuer endpoint; applications that authenticate against multiple instances trust each instance’s keys independently. Compromise of an instance’s signing key is a per-instance scope, not a deployment-wide event — recovery requires revocation of that key and JWKS refresh at downstream validators, but does not propagate to other instances’ signing keys.

Authonomy-native credentials. Credential material registered with Authonomy lives in the deployment’s credential store: the instance database by default, or an externalized keystore where the deployment selects that overlay. Three credential types are stored:

• WebAuthn public keys. Per-user public keys registered with Authonomy as the relying party. The private material never leaves the user’s authenticator; public keys are not sensitive on disclosure.
• TOTP seeds. Shared secrets between the user’s authenticator app and Authonomy. Encrypted at rest, held in a form that permits verification at the instance without exposing the seed to logs or operator inspection.
• Password hashes. Computed at enrollment using a modern memory-hard password-hashing function with per-user salt and a configurable work factor. The plaintext is not retained beyond the verification window of the enrollment ceremony, and is not transmitted in cleartext between instances or between an instance and the credential store.

Compromise scope and recovery

The compromise analysis distinguishes the topology choices, because the exposure shape differs:

Database-resident credentials, single-instance or shared-database topology. Compromise of the database exposes credential material for the deployment population held in that database. Recovery requires credential rotation for the affected population — re-enrollment for WebAuthn and TOTP, password reset for password — and session revocation for sessions issued from the compromised database’s serving instances.

Envelope encryption with externalized keystore. Compromise of the database exposes encrypted credential material, but not the wrapping keys held in the keystore. Recovery depends on whether the attacker also obtained cached keys or live keystore access. Compromise of the keystore exposes the wrapping-key authority and may require key rotation plus rewrapping or re-enrollment, depending on credential class and deployment policy.

Credential-in-keystore. Compromise of the database does not expose TOTP seeds or password hashes resident only in the keystore, though it may expose identity state, audit, session state, and credential references. Compromise of the keystore exposes the credential material it holds and is a deployment-wide credential-rotation event. Outage of the keystore prevents native verification for factors that require per-request keystore operations.

Customer’s primary IdP. Compromise of the customer’s primary IdP is outside Authonomy’s responsibility surface but bears naming because it propagates: the IdP authoritatively decides who exists, and Authonomy replicates that authority. Recovery is a customer-IdP incident-response path; Authonomy’s audit trail records what was absorbed and when, supporting forensic reconstruction once the upstream incident is known.

Transport and at-rest posture

TLS is used on every network path: application-to-instance, instance-to-identity-provider, and the credential-store path (whether replication into each instance’s canonical view in database-resident topologies or per-request keystore access in externalized topologies). TLS termination and certificate lifecycle follow the customer’s standard posture; the platform doesn’t require a particular CA or certificate provider.

At-rest encryption is applied to every persistent store at every instance: the session and state store, the canonical view, the audit trail, and the credential store. An instance physically accessible to non-operators carries an additional at-rest consideration: storage must be encrypted because the canonical view includes credential material.

Operational detail of the cryptographic primitives — specific algorithm suites, key lengths, password-hashing parameters — is addressed in the deployment’s operational documentation rather than this overview.