Aeion Auth + Generic OIDC — Federate from Any IdP
Connect Okta, Auth0, Ping Identity, OneLogin, JumpCloud, Keycloak, Authentik, ZITADEL, or any other OIDC-compliant IdP via Aeion's `oidc` provider. One code path; configuration via env-vars only. The right answer when your customer's enterprise already runs an IdP and you don't want to maintain N per-IdP code branches.
When This Integration Matters
Almost every enterprise customer already has an identity broker — Okta is the dominant one (~$3B ARR), Auth0 (acquired by Okta), Ping, OneLogin, and JumpCloud are the runners-up. Your customer's IT team doesn't want to reconfigure their workforce identity around Aeion; they want Aeion to delegate authentication to their existing IdP.
What Counts as "OIDC-Compliant"
Aeion's oidc provider works with any IdP that exposes a standard OAuth 2.0 authorization-code flow with a userinfo endpoint. In practice this is every modern IdP, but the concrete requirements are:
Step 1 — Register Aeion as a Relying Party at Your IdP
Every IdP has its own UI flow, but the shape is the same.
Step 2 — Aeion Auth Config
One env-var block, with the endpoint URLs set explicitly (there's no discovery-document fetch, so all three URLs are required).
Per-IdP Example Configs
Since Aeion doesn't do discovery-document fetching, you'll pull the concrete authorize/token/userinfo URLs from each IdP's own OIDC discovery document (<issuer>/.well-known/openid-configuration) and set them explicitly. For example, Okta's discovery document for an authorization server at https://acme.okta.com/oauth2/default resolves to:
Group Claims → Aeion RBAC Roles
Aeion's generic oidc provider doesn't currently read or map group claims to RBAC roles — it only extracts sub, email, and name from the userinfo response. If you need group-to-role mapping, you'll need to build it in your own application logic (e.g., a post-sign-in hook that inspects the raw profile data Aeion stores and assigns roles accordingly), or provision users into Aeion with roles pre-set via SCIM 2.0 (available on the auth module independently of the OIDC sign-in provider).
Common Gotchas
- Wrong endpoint URLs — since there's no discovery fetch, a typo or wrong path in
OIDC_AUTHORIZE_URL/OIDC_TOKEN_URL/OIDC_USERINFO_URLfails silently until a user tries to sign in. Double-check each URL against your IdP's own discovery document before going live.
FAQ
Don't. The dedicated providers have shortcuts the generic OIDC doesn't (Google's `hd` Workspace restriction, Microsoft's tenant-aware endpoint rewriting). Use `oidc` for IdPs that DON'T have a dedicated provider.
This page covers OIDC, but Aeion also supports **SAML 2.0** natively — if your IdP is SAML-only, configure a SAML connection instead (see Auth). Either protocol federates your IdP; pick whichever your identity provider exposes.
Spin up a local Keycloak with Docker Compose and configure Aeion against it using Keycloak's realm-specific authorize/token/userinfo URLs.
Not today — Aeion doesn't fetch the `.well-known/openid-configuration` discovery document. You set the authorization, token, and userinfo URLs explicitly, which you can pull from that same discovery document manually.
Not supported today — Aeion has one OIDC provider slot per deployment. If you need multiple upstream IdPs, front them with a broker IdP that itself speaks OIDC to Aeion.