The useful part of central login is not saving one password prompt. It is giving several applications a consistent identity boundary while allowing each application to keep its own permission model.

In my setup, Keycloak supplies identity and the applications retain responsibility for their local users, teams, records, and actions. That split is what makes single sign-on useful without turning the identity provider into an all-purpose business database.

Authentication answers only one question

A successful login establishes who authenticated through a particular flow. It does not automatically grant access to every CRM record or the right to moderate a meeting.

The conceptual chain is:

authenticated identity
  → application-local user
  → roles and team membership
  → permission for the requested action

The last step still has to happen on every protected server-side operation. Hiding a button or using an unusual route cannot replace it.

This separation also helps when changing application roles. An identity can remain valid while its access to a particular application is removed.

Give applications separate clients

A CRM backend and a browser-based meeting login do not have the same authentication requirements. I use separate OIDC clients so redirects, audiences, and credential handling can be configured for each application.

A server-side confidential client can keep a client secret. A public client cannot protect a secret shipped to the browser; its flow needs the appropriate public-client controls, including PKCE where configured.

Exact callback configuration matters. Broad redirect patterns can turn a convenience setting into an unintended place to send authentication responses.

Token verification is more than decoding JSON

A token's readable claims are not proof that those claims are trustworthy. The relying application needs the expected issuer, intended audience, valid lifetime, and a signature verified using trusted keys.

That creates a real operational dependency: the application must be able to obtain verification keys through its actual runtime network and resolver.

A successful request from the host does not prove that a service inside a rootless container can reach the same endpoint. That distinction became especially relevant in the meeting stack.

Group mapping is a synchronization problem

Mapping identity-provider groups to application teams reduces manual setup, but it adds lifecycle questions. When is membership refreshed? What happens when a group is removed? Which local memberships are managed by the integration and which belong to the application?

A login test with one administrator cannot answer those questions. Useful cases include a new regular user, an existing user, removed membership, and an account without access.

Central authentication makes onboarding and MFA policy more coherent. It also makes identity infrastructure a dependency worth monitoring and recovering deliberately. Keeping a controlled administrative recovery path is part of that design, rather than evidence that SSO failed.