Architecture

Where Authonomy sits in the identity estate.

Authonomy sits between governed applications and identity providers, and alongside the administrative and governance systems used to operate the estate.

Explore the platform Talk to us

One product, two responsibilities

Applications get one identity boundary. The enterprise gets one view of the estate.

Applications New, federated, and older web applications

Application Identity Runtime The identity boundary applications use

Identity providers Continue to run their authentication journeys

Enterprise Identity Control Plane See the estate, direct change, and check the result

Connects to

Provider administration Identity governance Audit and assurance

Application Identity Runtime

Applications point to Authonomy. Authonomy connects to the provider.

Federated applications connect over OpenID Connect or SAML. Older web applications use a protected path that supplies identity in the form the application expects.

The application-facing contract and the upstream provider relationship are separate. This lets the enterprise change the provider path while preserving the contract the application uses.

Enterprise Identity Control Plane

Teams approve change in Authonomy. Authonomy works through each connected system.

Authonomy observes connected systems through their administrative interfaces. When teams approve a change, it applies the permitted update through the same interface and checks the resulting state.

Ownership

Clear boundaries across the estate.

Authonomy owns

The identity contract presented to each governed application
The model of applications, providers, and their relationships
Approved intent for cross-provider change and evidence of the result

Other systems keep

Identity records and authentication journeys in providers and directories
Access governance decisions in IGA systems
Application sessions, roles, and business permissions in applications and their authorization services

Failure boundaries

What continues and what stops.

Authonomy fails closed when it cannot establish the required identity contract or safely complete a change.

An identity-provider path is unavailable

What continues: Applications with another approved path use it when it satisfies the same identity contract. Existing application sessions remain under the application’s control.
What stops: Sign-in is denied when no approved path satisfies the contract.

Authonomy services are unavailable

What continues: Existing application sessions remain under the application’s control.
What stops: New sign-in and administrative changes stop until service is restored.

An administrative operation fails

What continues: The intended change and the last confirmed state remain visible.
What stops: The operation is not recorded as complete until the result is verified.

Event	What continues	What stops
An identity-provider path is unavailable	Applications with another approved path use it when it satisfies the same identity contract. Existing application sessions remain under the application’s control.	Sign-in is denied when no approved path satisfies the contract.
Authonomy services are unavailable	Existing application sessions remain under the application’s control.	New sign-in and administrative changes stop until service is restored.
An administrative operation fails	The intended change and the last confirmed state remain visible.	The operation is not recorded as complete until the result is verified.

Explore identity continuity →

Review the placement against your estate.

We’ll map the application boundary, provider authority, governance systems, and dependencies for a concrete part of your environment.

Talk to us