Repository navigation
Replies: 9 comments 7 replies
|
I'm far from being an expert here, and we're using the MSAL library to log in. Since 26.1.0, what used to work fine doesn't anymore (reloading the page after login, which tries to make a silent SSO login fails because a new interactive login is required). I must confess I have no idea of what to do to successfully make an OIDC login after this change. |
|
Feel free to put this request into an enhancement issue, this is more likely to get the attention of the relevant teams due to triage, and allows users to upvote it if this is relevant to them, which helps us set priority. |
|
@jnizet you probably have scope I'm thinking of working around server-side by implementing a custom required action (that could be applied to certain clients that rely on the old behaviour) to remove the note that triggers the online session removal: @jonkoops Thanks for the feedback. I will follow your suggestion and create an enhancement issue. |
|
I've tried that: // ...
from(msalInstance.loginPopup({ scopes: SCOPES.filter(s => s !== 'offline_access') })).pipe(
switchMap(() => msalInstance.loginPopup({ scopes: SCOPES }))
)
// ...but
I have no idea if it's MSAL doing the something wrong, if it's me using it incorrectly (but it worked absolutely fine before 26.1.0), or if it's Keycloak not respecting the standard that MSAL expects it to follow. |
|
I appreciate this change could cause some issues for some, but the previous behaviour was actually buggy and a security issue. If you request and offline session only the offline session should be returned, and the previous behaviour left in many cases a dangling session. Could you elaborate more on why this change was problematic? For any clients that need both an online and an offline session, I would presume they are already doing two separate OAuth requests, as otherwise they would not have access to any tokens associated with the "online" session. Now, if an application requests an "offline" session first, and an "online" session second (that is of course the wrong order, but hey), the downside is that the user has to authenticate again to establish an online session, but that is the expected and proper behaviour. |
|
Thanks for your feedback!
This seemed to work nicely until Keycloak 26.1 (our systems were migrated from Auth0 to Keycloak a few months ago - and also using Auth0 this was the behavior we were relying upon). Starting with 26.1, users of the last scenario that want to use another application within the online session period, now have to re-authenticate.
In fact, they don't right now. However, I can confirm that if we would do 2 authentication flows (first
I'm not sure if I understand this. Thanks again for your thoughts on this. |
|
Wondering why you are using offline sessions for regular apps in the first place? Is that to have durable sessions for the apps (i.e. a permanent logged-in mobile app). We now have support for persisted sessions in Keycloak, which is a lot better fit for this purpose IMO, as it couples multiple apps together into a single durable session, where the user can logout the device, rather than having to revoke offline access to individual applications. Bear in mind that the real use-case for offline sessions are really to grant an application/services access on behalf of the user when the user is not present (think more a backup service or something like that). |
Yes, both in mobile apps and single-page webapps. Our online sessions currently expire a lot faster than offline sessions. And only a limited number of applications are allowed to use offline_access. So even when the online session expires, those apps can still access their APIs with a refreshed access token.
This is a very interesting idea. We switched to using persisted sessions recently, so I hadn't thought about using it for this purpose. Until this feature though, I think offline_access was the only way to achieve the requirement of having durable sessions. But going forward, using persistent online sessions, I think we could do this for clients that need a long session:
As a result:
I will give this a try and see if there are any other side effects that I didn't think of. |
|
Our use case is an app that the user logs in to, and the backend wants to maintain the login on the user behalf. Hence, we'd like to start the SSO session in the browser, at the same time as requesting an offline session for the backend system. The old behaviour is exactly how similar SaaS solutions like auth0.com or ORY Hydra behave. Both allow starting an SSO session at the same request that is requesting the offline_access scope. I think the change is unreasonable and breaking existing functionality. Breaking changes should result in a major version update. But more importantly: Why push the responsibility to the client to send two requests for one login? It seems unreasonable to change the old behaviour, especially as it is common in other providers. Can you elaborate why you want to push this extra requirement on the client to do two requests? |
|
I guess you have read the thread above: we have the same use case and we might change to using longer online sessions for that specific case (we have other use cases where we request offline sessions, without the need to maintain the online session, so that is where we would like to have the new behaviour). However, while this change in being analysed, we were able to upgrade to 26.1 by temporarily reverting this change using a custom LOGIN event listener that removes "first.offline.access" from the client session. That way the online session won't be removed here |
|
We have discovered rare issues with this change as well. We start an OIDC auth flow with the requested scope "offline_access" and the client successfully retrieves an access token from the /token endpoint. However, it happens that this access token can not be used to call the /userinfo endpoint. The reason: UserSessionUtil.checkTokenIssuedAt(...) (see https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/services/util/UserSessionUtil.java#L139) says the token was issued before the start of the offline session. This is no surprise, as the offline session is created in PersistentUserSessionProvider.createOfflineUserSession(...) (see https://github.com/keycloak/keycloak/blob/main/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/PersistentUserSessionProvider.java#L675) after the access token has been created, and the offline session takes Time.currentTime() as its started property. Instead, it should take the started property of the corresponding online user session (before the online session is finally deleted). |
|
I'd like to join this discussion. The purpose of For some use cases this makes sense, but in many real-world scenarios it creates serious UX problems. A good analogy: I shouldn't have to be logged out of YouTube with my personal account just because I'm staying logged into Gmail with my work account — without resorting to browser profiles. The current behavior feels broken: any app requiring offline tokens effectively loses proper SSO functionality. One suggested workaround is to issue an online session first, followed by an offline one. But has anyone actually tried this on iOS with The user sees an iOS security prompt, a browser window opens, the user logs in — creating the online session This raises a broader question: is Keycloak actually designed with mobile apps in mind? Many of these discussions seem to focus exclusively on desktop and browser-based implementations. Furthermore, using online sessions for apps would require extremely long session lifetimes — which is precisely what you want to avoid for browser sessions. The inability to flexibly combine both session types due to broken SSO is not a minor inconvenience; it is a fundamental architectural limitation that forces developers into an uncomfortable tradeoff between security best practices and usability. |
|
I'd like to add another dimension to this discussion that hasn't been explicitly addressed yet. App A and App B share the same session With offline sessions: Each app has its own independent refresh token This is a completely legitimate and widely used pattern: SSO for the initial authentication, combined with per-app session isolation during ongoing usage. Auth0, Okta and other major providers support this natively — you get SSO on first login, and independent sessions per app afterwards. |
|
@stianst : Any feedback on the above comments? |
|
@stianst Thank you! In my case this is causing an SSO UX problem, and we don't necessarily control the clients! So we can't always modify them to establish two kinds of sessions. I'm wanting to let my company users SSO to MCP servers that have been configured in Claude. But Claude requests the In summary, my issue isn't about a single client. I don't need two kinds of sessions for one client, per se. But I do want some |
Uh oh!
There was an error while loading. Please reload this page.
First of all, great work with Keycloak 26.0.1 👍
Since this change #32650 in Keycloak 26.1.0 there is a breaking change in the SSO behavior as explained in https://www.keycloak.org/docs/latest/upgrading/index.html#migrating-to-26-1-0 (under Notable changes)
While I understand why this was changed, our use-case does rely on both online (for SSO on other clients) and offline sessions (for staying logged in at the same client). I would like to discuss what the options are to go back to the previous behavior, being the creation of both an online and offline session when the first authentication is done using
offline_accessscope.The obvious way of getting the same behavior is changing the client to perform 2 steps:
(Side note: I had to read through the Github issue comments to find this - it would be nice if this work-around would be listed in the migration guide itself)
However, this requires:
Would it be possible to trigger the old behavior without the need to change the client?
Many thanks for any feedback.
All reactions