🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.

Azure AD / Okta / standard OIDC

This page is where the provider abstraction (see F1 Integration principles) pays off: connecting a second or third Human IAM does not require changing GenAuth's core, only a new provider implementation. Below is how the three providers on the roadmap will integrate — concepts only, no configuration steps, because they do not exist yet. When they do, they will live on this page.

All three share one integration language: the three capability surfaces of the provider interface.

Capability surface	Question it answers during integration
Federated login	Which enterprise account does the user sign in with at consent time
Directory reads	Does the delegating user exist, and how is their identity mapped
Permission evaluation	The person's real permissions — the attenuation floor of the three-way intersection

How Azure AD (Entra ID) will integrate

• Federated login: the standard OIDC authorization code flow against the Microsoft identity platform. The consent screen redirects to enterprise-account login, and the identity assertion returns to GenAuth.
• Identity mapping: a stable directory object identifier within the tenant is the user mapping key — conceptually the object ID class of claim in its identity assertion — so renames and email changes never break who a delegation record belongs to.
• Permission evaluation and scope mapping: read-only assertions about directory groups and app roles are the input. "Alice ∈ some group / holds some app role" is translated by the mapping layer into a ceiling allowlist of delegatable scopes — narrowing only, never widening.

How Okta will integrate

• Federated login: the standard OIDC authorization code flow against Okta, same shape as above.
• Identity mapping: the stable user identifier in the Okta directory is the mapping key, so delegation records anchor to the directory entry rather than a login name.
• Permission evaluation and scope mapping: group assertions (the groups class of claim) plus custom claims issued by the authorization server feed permission evaluation, and pass through the mapping layer into the three-way intersection.

How standard OIDC will integrate

The standard OIDC provider is the fallback channel: any compliant IdP that implements OIDC Discovery and the authorization code flow can be connected as an identity federation source.

• Federated login: discover endpoints through OIDC Discovery, run the standard authorization code flow. sub is the default user mapping key, with support for overriding it via a custom claim.
• The honest limit of permission evaluation: the OIDC standard only guarantees the identity layer. If your IdP exposes readable permission assertions (group or role claims, or a read-only permission API), the mapping layer works as usual. If it does not, the "person's real permissions" set in the three-way intersection cannot be evaluated, and attenuation degrades to a two-way intersection: explicitly delegated scope ∩ organization's approved boundary. The docs will say so plainly at the relevant configuration point rather than pretend an evaluation happened.

Help us order the roadmap with your requirements

Implementation order is driven by real demand. If your organization runs one of these IdPs and wants it prioritized, tell us three things: which one you run, what your permission model looks like (groups / roles / permission points), and which capabilities you want to delegate. That input feeds directly into scheduling. In the meantime, read Connect your existing identity stack for an onboarding path that does not depend on any specific provider.

Next steps

• Principles: Integration principles: how OIDC and OAuth scopes connect — the provider abstraction and the three integration layers
• Reference point: Connect Authing — what an implemented provider integration looks like
• Guide: Connect your existing identity stack — the path you can take today