OIDC Login (SSO)

The SSO button takes the user to the provider’s login page. YEKE never receives the password. After authentication, YEKE creates a session using the Authorization Code + PKCE flow.

The local username-and-password form does not disappear. That is not an oversight but an emergency access path: the install owner is always local, so local administrator login stays available when the provider is unreachable or misconfigured.

The SSO button is only drawn on the login screen when two conditions hold together: an enabled provider must be defined and the license must carry the Enterprise sso item. That item is shared with Active Directory / LDAP login — there is no new license flag, and both can be enabled at the same time.

label             :  Corporate account
issuer            :  https://id.example.com/realms/corp
client id         :  yeke
client secret     :  (write-only)
username claim    :  preferred_username
groups claim      :  groups
admin group       :  yeke-admins

Before you save, the "Test connection" button really fetches the provider's discovery document, resolves the endpoints and writes them into the record. If the test fails, the reason shows up on screen; the record is still stored, but not enabled.

Only one provider can be enabled at a time.

The return address from the provider is built by appending /api/auth/oidc/callback to YEKE_PUBLIC_URL. That address has to be registered on the provider side exactly like this.

YEKE_PUBLIC_URL  :  https://yeke.example.com
redirect URI     :  https://yeke.example.com/api/auth/oidc/callback

Roles can be derived from the directory

The provider record lets you optionally name an admin group (adminGroup). When set, a user's role is derived from the token's group claim on every login, and writing that user's role from the UI is refused — otherwise a manual edit would be silently overwritten by the next login. Leave it unset and the role is managed the usual way, from YEKE's user screen.

Kubernetes identity: the same list as the directory

The cluster rule plus personal binding model described on the Permissions and RBAC page still applies. The token's group claim is written into the same mapping list in the cluster identity rule: there is no separate list for LDAP and another for OIDC. One list carries both LDAP group DNs and OIDC's plain group names.

source group                                      Kubernetes group
CN=YEKE-Operators,OU=Groups,DC=example,DC=com  →  yeke:cluster-admins    (LDAP)
yeke-operators                                 →  yeke:cluster-admins    (OIDC)
3f2b9c14-8a71-4d0e-9c53-6b7a1e5d20f4           →  payments-oncall        (OIDC)

Keycloak: "full path" must be off in the group mapper

Keycloak's group mapper can emit the group's full path (/parent-group/child-group). If you want to write plain group names in the mapping list, that option has to be off — the plain name landing in the claim depends on it.

Entra ID emits GUIDs in the group claim

Entra ID puts a group's GUID, not its name, into the group claim; the value you write on the left side of a mapping row is that GUID. An optional label can be written on the row — a list of nothing but GUIDs becomes unreadable.

Registering an application in Entra ID

Before you can connect Microsoft Entra ID as a provider, you need to register an application on the Entra side: the application registration, the client secret, the admin group and the token's group setting are all covered step by step on the Entra ID SSO Setup page.

• Just-in-time creation. A user who authenticates against the provider but has no YEKE record yet is created automatically on their first successful login.
• It consumes a seat. An automatically created user consumes a license seat exactly like one created by hand. If the seat ceiling is reached, the login is refused with an explicit code.
• The username comes from the claim. The name YEKE stores is the value of the claim you chose in usernameClaim; that is the name shown in the user list and the audit trail.
• A login is refused if an account with the same name exists. If the incoming username collides with an existing local or LDAP account, the login stops with a loud error; the OIDC user is not silently attached to that account. Silent attachment falls into the account-takeover class.

• An OIDC user cannot enroll YEKE's own TOTP. The provider decides who is asked for a second factor; YEKE does not open a second factor record for the same user.
• Nothing changes for local accounts. YEKE's own second factor stays exactly as it is for local users.

• No SAML or SCIM. Everything on this page is about OIDC; SAML and SCIM remain in the demand-driven queue.
• End-to-end Entra ID login was tested against a real tenant. Group object ID (GUID) → role and Kubernetes group mapping was part of the same test; this landed in 0.46.1 — earlier releases could not even register Entra ID as a provider. Still unverified: Entra's "groups overage" behavior for a user who belongs to many groups, and whether the user identity (sub) changes when an app registration is recreated.
• A login is refused on Entra "groups overage". When a user belongs to too many groups, Entra ID does not emit the group claim at all. YEKE refuses the login in that case; it does not silently continue with an empty group set, because that path would leave the user without access and without any error.
• One enabled provider at a time. There is no keeping more than one OIDC provider enabled simultaneously.
• A YEKE session does not end when the IdP session does. There is no back-channel logout: YEKE holds its own session, and the provider's token is used only at login and never stored.
• None of this works without a license. Provider configuration and OIDC login are refused with an explicit error without the Enterprise sso item; local login is never affected.