I've tried that:

// ...
from(msalInstance.loginPopup({ scopes: SCOPES.filter(s => s !== 'offline_access') })).pipe(
  switchMap(() => msalInstance.loginPopup({ scopes: SCOPES }))
)
// ...

but

• the second login is not silent at all: ir redisplays the popup
• once that is done, refreching the page and trying to execute msalInstance.ssoSilent({ scopes: SCOPES }) throws an error indicating that an interactive login is required again.

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.

Thanks for your feedback!

Could you elaborate more on why this change was problematic?

• Our system consists of several separate applications that all use the same login and use access tokens issued by Keycloak to authorize API endpoints.

• All of our applications rely on the online session being created, so the user doesn't have to re-authenticate if it starts authentication from another client. These clients start authentication using scope=openid. After authenticating on client A, the user can authenticate on client B without providing its password (within the timeframe of the online session)

• Some of our applications (usually single-page webapps) also rely on offline sessions because they use the refresh token as soon as the access token expires (after 24 hours) so the user doesn't have to re-authenticate. Those clients start authentication with scope=openid offline_access to be able to retrieve the refresh token.

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.

For any clients that need both an online and an offline session, I would presume they are already doing two separate OAuth requests

In fact, they don't right now. However, I can confirm that if we would do 2 authentication flows (first scope=openid, then scope=openid offline_access) it does work as expected. If this is the ultimate solution, then I'm sure we can change our applications to this. It would have been nice however if we could buy some more time so we don't have to do this the at the moment (or before) we upgrade to 26.1.

as otherwise they would not have access to any tokens associated with the "online" session.

I'm not sure if I understand this.
Our application is only interested in retrieving access tokens that can be used to authorize APIs from their custom endpoints. I don't think it matters that it's not associated with the online session? The online session serves another purpose for us: making sure the user doesn't have to re-authenticate within the period of the online session.

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).

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).

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.
Using offline_scope this way seemed very common at the time.

We now have support for persisted sessions in Keycloak, which is a lot better fit for this purpose IMO

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:

• remove offline_scope in their auth request
• configure those clients to have a long session idle/max value (equally long to their current offline session)

As a result:

• the client can still use the refresh token as usual
• the online session is created and the user can silently authenticate when using another app

I will give this a try and see if there are any other side effects that I didn't think of.

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
https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/protocol/oidc/grants/OAuth2GrantTypeBase.java#L118

I'd like to add another dimension to this discussion that hasn't been explicitly addressed yet.
The suggestion to use long-lived persistent online sessions does not fully solve the problem. The issue is not just about session lifetime — it's about session isolation.
With an online session (regardless of how long it lives):

App A and App B share the same session
If the user logs out of App A and the session is killed, App B is logged out as well

With offline sessions:

Each app has its own independent refresh token
If the user logs out of App A, only App A's token is revoked
App B remains logged in

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.
Recommending persistent online sessions as a replacement for this pattern misses the point entirely. Persistent sessions are still shared sessions, and shared sessions mean that a logout in one app affects all other apps.
This is not an edge case or a misuse of offline_access. It is a standard enterprise requirement, and it is especially critical for mobile apps where the user expects that logging out of one app does not silently invalidate their session in another.

@stianst : Any feedback on the above comments?