It is easy to assume that connecting inerit and the blog to the same Keycloak instance will naturally result in seamless login continuity. However, the fact that authentication servers are shared and the manner in which each service establishes a login state are separate issues.
During the work conducted in November 2026, logging in on one side did not result in continued authentication on the other side; reauthentication was required. Subsequently, we addressed bidirectional login integration, service-specific permissions, prevention of immediate relogin after explicit logout, and migration of existing accounts. This article presents the design lessons learned from the work records of that time. It does not represent a re-verification of the current operational status.
Central Authentication and Service Sessions Are Different
Even if a user is logged in to the authentication server, a newly visited service may not yet have verified that result. The service must verify the authentication state, undergo necessary validations, and establish its own login state. This differs from simply reading cookies from another service.
When diagnosing failures, questions must be separated.
- Does the authentication server have a valid SSO session?
- Has the new service initiated authentication verification?
- Did response validation and existing account linkage succeed?
- Do the users and permissions permitted by the service match?
Keycloak distinguishes between SSO user sessions and client sessions, and application-specific sessions may also exist separately. If expiration policies are viewed as a single entity, it is difficult to identify at which boundary the state was broken. Keycloak Session Expiration Settings
Automatic Login and Forced Login Are Different
Redirecting to the authentication screen every time a public page is opened, and continuing the login state only when existing authentication is present, are different policies.
For example, login-required and check-sso of the Keycloak JavaScript adapter provide different entry experiences. This is merely an example to illustrate the difference and does not imply that the corresponding options were used in inerit at the time. The prompt=none of OpenID Connect also only requests that processing occur without interaction; it does not omit authentication or consent. If necessary, a result such as login_required is returned. Blindly retrying this can result in repeated round-trips between the authentication server and the service. Keycloak JavaScript Adapter, OpenID Connect Authentication Request
Quiet authentication verification based on iframes is also affected by the browser’s third-party cookie restrictions. Success in one browser alone does not guarantee identical behavior across all environments.
Authentication and Usage Approval Are Separate
Central authentication verifies who the user is but does not automatically determine whether to allow access to a specific service. Even an account approved for one service may have different access conditions for another. In such cases, rather than asking for the password again, it is better to distinguish and inform users of pending approval or restricted access status.
Permissions can be expressed as Keycloak client roles or managed by the service itself. Whichever approach is chosen, verification must occur not only on the display side but also where protected requests are handled. User consent in the protocol and usage approval for service operation are distinct concepts. Keycloak Client Roles
Logout Includes User Intent
Even if the service session is cleared, the central SSO session may remain. In this case, if the page immediately resumes automatic login, the user sees a logged-in screen immediately after pressing the logout button.
First, it must be determined whether to log out from the current service only or to terminate the central session as well. If it is service-specific logout, it must also be decided how long to maintain the automatic login suppression state and how to release it upon an explicit login request. This state is for user experience and does not replace server-side authentication and authorization checks.
Central logout should also not assume that sessions and screens in other services are cleared immediately. OpenID Connect separately defines RP-Initiated Logout, which requests termination from the authentication server, and Back-Channel Logout, which handles inter-server notifications. The actual implementation must be verified based on service requirements and implementation details.
Account Migration and Verification
In migrating existing accounts, one cannot simply check if login works. It must be confirmed that data ownership and service-specific approval statuses are linked to the correct account, and that there are no unclear or duplicate accounts. The standards for handling identifier stability in OpenID Connect are a combination of iss and sub. However, the presence of this identifier does not automatically prove a link to an existing local account. OpenID Connect Identifiers
During verification, following state transitions is more important than a single successful login.
- Does the intended authentication flow work when moving from any starting service to another service?
- Does an unauthenticated user avoid being trapped in a login loop on public screens?
- Is appropriate guidance displayed when authenticated but lacking usage approval?
- Is the intended policy maintained after explicit logout, including after refreshes and revisits?
- Can recovery occur even if the central session and service session expiration points differ?
- Are data and permissions for existing accounts correctly maintained?
The core of SSO does not end with merely reducing the number of login screens. One must decide where to manage the identity verified by the authentication server, and the sessions, permissions, and user logout intents of each service separately.
