Integration principles: how OIDC and OAuth scopes connect
Agent Identity does not replace your Human Identity stack. It sits on top of it. Through one provider abstraction, GenAuth connects three things to the Human IAM you already run: who the user is (identity federation), what the user can do (permission reads), and how delegation is expressed (scope mapping).
Why connecting is mandatory: permissions originate in Human IAM
Authority always originates from people. Every ounce of power an agent exercises is explicitly handed over by a person from your Human Identity stack — narrowable, auditable, revocable at any moment (see What GenAuth is). Translate that worldview into engineering and you get the three-way intersection of attenuation:
An agent's effective permissions = the person's real permissions ∩ the explicitly delegated scope ∩ the organization's approved boundary
Two of those three sets belong to GenAuth: "the explicitly delegated scope" comes from consent, "the organization's approved boundary" comes from agent registration and approval. But "the person's real permissions" has exactly one authoritative source: the Human IAM you already run. Users, organizations, roles, and permission policies live there — and they change every day.
Skip the connection and three gaps open up:
- An identity gap — GenAuth is forced to stand up a second account store. "Alice" becomes two different people, and delegation records no longer line up with your enterprise directory.
- Attenuation loses its lower bound — if you do not know what Alice herself can do, you cannot honor "you cannot delegate a permission you do not have".
- Two permission languages talk past each other — Human IAM says "read-only role on the reporting system", delegation says scope, and nothing in between translates.
One thing up front: connecting is not migrating. Your users, organizations, and permission model all stay where they are. GenAuth only federates, reads, and maps — it never takes over and never writes back. For the full onboarding path, see the flagship guide Connect your existing identity stack.
Layer 1 · Identity federation — who the user is
Delegation begins with a consent step, and consent rests on one assumption: the person in front of the consent screen is the person in your enterprise directory. Identity federation settles that with standard OIDC. At consent time the user is redirected to your Human IAM to sign in, the identity assertion returns to GenAuth, and the delegation record is anchored to a real directory user from its first line onward.
In the self-hosted same-domain sidecar model this is hop ⑧ of the full journey. The SaaS model has no such hop — there the user directory is hosted on the tenant side (see Deployment models):
What the federation layer buys you directly: the single sign-on experience does not change, passwords never pass through GenAuth, and deactivating someone who leaves happens once in Human IAM — the delegation side follows on its own.
Layer 2 · Permission reads — what the user can do
Hop ③ above answers the first set in the three-way intersection: the person's real permissions. GenAuth asks Human IAM for a read-only permission evaluation — does Alice actually hold the permission she wants to hand over — and only lets the delegation proceed to issuance once the permission assertion comes back.
This layer has three rules. Every one of them is hard:
- Read-only — GenAuth evaluates, never modifies. Nothing gets written back into your permission model.
- Real-time — the assertion is evaluated at issuance. A staff transfer or a revoked role takes effect on the very next delegation issued.
- Intersect, never widen — a permission assertion can only narrow a delegation. It never adds a permission the person did not have.
For the full mechanism, including why every hop can only narrow, see Delegate Token and attenuation.
Layer 3 · Scope mapping — aligning the language of delegation
The permission vocabulary inside Human IAM (roles, groups, permission points) and delegation scopes (authorization slices shaped service.capability:action) are two different languages. Scope mapping is the translation layer in between, and it does three jobs:
- Vocabulary alignment — maps directory-side assertions (say, "Alice ∈ reporting-read-only group", illustrative) onto an allowlist of delegatable scopes.
- Granularity alignment — roles are coarse, scopes are fine. A role unlocks the delegatable ceiling for a set of scopes; on the consent screen the user can still tick only part of it.
- Change propagation — authorization changes on the directory side flow through the mapping layer into delegation. Revoke a role and the matching scopes drop out from the next issuance onward.
Mapping runs one way only: directory assertions enter the three-way intersection as input, and delegation scopes never rewrite your permission model.
The provider abstraction: one interface, many Human IAMs
The three integration layers converge into three capability surfaces on the provider interface: federated login, directory reads, permission evaluation. Each Human IAM's protocol details — endpoint shapes, claim names, directory APIs — stay encapsulated inside its own provider implementation, and GenAuth's delegation engine only ever faces the unified interface. Supporting the next IdP means adding a provider, not changing the core.
The provider roster has exactly two columns — implemented, or on the roadmap. There is no third state:
| Implemented | Roadmap |
|---|---|
| Authing | Azure AD (Entra ID) |
| Okta | |
| Standard OIDC |
Every provider page states its integration shape, configuration items, and current progress honestly.
Standards and the compatibility roadmap
| Standard | Where it sits in the integration |
|---|---|
| OpenID Connect Core 1.0 | Protocol foundation of the identity federation layer: enterprise login + identity assertion |
| OAuth 2.0 (RFC 6749) | Scope as the language for expressing delegated authority |
| Token Exchange (RFC 8693) | Exchange and delegation semantics for the Delegate Token — see B3 |
| IETF AAT draft | The standardization track for "every hop only narrows" (attenuation) |
Compatibility statement: ID-JAG (Identity Assertion Authorization Grant, a standard in progress at the OAuth working group) and its commercial form XAA are writing "the enterprise IdP as the decision point for cross-application authorization" into the spec. GenAuth's provider abstraction treats that as a committed compatibility direction for the identity federation layer: we integrate once the protocol lands, with no private fork.
Next steps
- Get started: Connect Authing — the configuration page for the implemented provider
- Guide: Connect your existing identity stack — the full path that leaves your current IdP untouched
- Architecture: Deployment models — where SaaS and the self-hosted same-domain sidecar draw different boundaries