Keycloak & OIDC providers
Admin sign-in is SSO-first (the model is explained in Enterprise SSO). This page is the setup reference: the bundled Keycloak, your own Keycloak or IdP as the issuer, and federation — plus the three configuration details that cause most integration failures.
Option 1 — the bundled Keycloak (default)
Every standalone install bundles Keycloak behind the same host at /auth, in production mode, on the bundled PostgreSQL. The installer renders the realm for your public URL, and prints a one-time admin password; first sign-in forces a change. Nothing to configure.
Administer it at https://<host>/auth/admin — this is also where you set MFA policies, token lifespans, and session caps.
Option 2 — your own IdP (Keycloak, Entra ID, Okta, Google)
-
Register a confidential OIDC client (authorization-code flow) with redirect URI:
TEXThttps://<your-host>/login/oauth2/code/aim-dashboard -
Add the audience. Tokens must carry
aim-admin-apiinaud. In Keycloak that is an Audience protocol mapper on the client or a client scope; in Entra/Okta, an equivalent audience/claim configuration. IdPs do not emit custom audiences by default — without this, every token is rejected with401. -
Map the admin role. Map your admin group to a realm role named
admin; it becomes the platform-admin authority (ROLE_ADMIN) on/admin/**. A token without it gets403. -
Configure the gateway in
deploy/.envand install with--idp custom(omits the bundled Keycloak):CommandAIM_OIDC_ISSUER_URI=https://keycloak.example.com/realms/aimanager AIM_OIDC_CLIENT_ID=aim-dashboard AIM_OIDC_CLIENT_SECRET=...Setting the issuer is what turns OIDC on; the audience list is required alongside it. OIDC is additive — the break-glass Basic admin keeps working.
Option 3 — federate inside the bundled Keycloak
Keep the bundled Keycloak as the issuer and connect your corporate identity behind it: Identity Providers (another OIDC/SAML IdP) or User Federation (LDAP / Active Directory) in the Keycloak console. No gateway configuration changes at all — useful when you want AD sign-in without touching your central IdP's app catalogue.
Verifying a token by hand
# Obtain a token from the IdP (direct-access grant, for testing only)
TOKEN=$(curl -s -X POST "$ISSUER/protocol/openid-connect/token" \
-d grant_type=password -d client_id=$CLIENT -d username=$USER -d password=$PASS \
| jq -r .access_token)
# Call the Admin API with it
curl -s -i -H "Authorization: Bearer $TOKEN" https://aam.example.com/admin/me
401 means the token failed validation — most often the missing audience. 403 means it validated but lacks the admin realm role.
Hardening checklist
All at the IdP, which requires nothing from the gateway:
- Short access-token lifespan (a few minutes); the gateway holds no session and validates every request.
- Refresh-token rotation with reuse detection; idle and absolute session caps.
- MFA as a realm policy for admin users.
- Once SSO is verified, treat the Basic admin strictly as break-glass and monitor Govern ▸ Sign-in activity.