Logout of offline session logic

[Hynek Mlnarik]

Hi,

I am trying to find a reason for what seems to me an inconsistent behaviour of online and offline session logout.

Currently, the logout of a session uses the following logic:

1) Determine at the logout endpoint whether the token used in logout session belongs to offline or online session

2) If the session is online, logout only this online session

3) If the session is offline, logout the offline session and also logout the online session that was used to create this offline session, if it exists

This means that:

1) User has existing offline session with ID 1

2) User creates a offline session (using online session) with ID 2

Now:

a) if the user logs out offline session 1, both online and offline session 2 would remain active

b) if the user logs out offline session 2, both online and offline session 2 would be logged out, session 1 will remain active

c) if the user logs out online session 2, only online session 2 would be logged out, offline sessions 1 and 2 will remain active

This seems to be inconsistent behaviour to me - I believe that in an consistent world either both of the online and offline session would be logged off in case b) and c) (that would however effectively render offline sessions useless) or only one of the offline and the online session would be logged off, depending on the token passed to the logout endpoint.

I seem to be missing some strong argument for the current behaviour.

I struggle to be convinced only by the fact that in the current storage, the corresponding online and offline sessions share the same ID.

Thanks for explanations. On the other hand, I'm happy to be convinced that the right way would be to treat online and offline sessions independently.

--Hynek

[Pedro Igor Craveiro e Silva]

We had this discussion in one of the PRs for logout.

Basically, online and offline sessions are related to distinct use cases. This behavior is backed by specs as per https://openid.net/specs/openid-connect-backchannel-1_0.html.

We kind of mix these two concepts in Keycloak. And I think some of the issues with offline are related to this conceptual problem. The same for people using offline to overcome expiration and refreshes.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAMvXD%3DFOZJxUZJNxPzkTXYfrs_JgbDRNVg3KfpeeRakoB_apwA%40mail.gmail.com.

[Hynek Mlnarik]

I still would like to understand the reasons why the current implementation behaves as it does. Any pointers to discussions would be much appreciated. So far it seems to me that the inconsistency is should have never been there.

Ad spec - could you please point me where exactly the spec describes this behaviour? The only mention of offline tokens is in Section 2.7. Back-Channel Logout Actions, and as far as I read it, there is no mention that logout of an offline session should log out an online session as well. The only sentence touching a bit the topic there is "The RP then clears any state associated with the identified session(s)." However, it does not follow that the identified session of the offline session would also be the online session.

[Pedro Igor Craveiro e Silva]

On Wed, Mar 31, 2021 at 8:25 AM Hynek Mlnarik <hmln...@redhat.com> wrote:

I still would like to understand the reasons why the current implementation behaves as it does. Any pointers to discussions would be much appreciated. So far it seems to me that the inconsistency is should have never been there.

I don't know all the motivation behind the current implementation. AFAIK, it has been there for a long time.

The only inconsistency I can see is the fact that we are using logout to destroy offline sessions. And that is the reason why I mentioned the misconception around offline sessions.

That said, none of the options you gave to achieve consistency makes sense for me. The core issue (and a conceptual one, IMO) is offline sessions treated like online sessions and their usage in the logout endpoint.

The fact we destroy online when "logging out" offline is our interpretation, probably motivated by some use case. And I don't see how to make that consistency without dropping offline sessions from the logout endpoint.

 

Ad spec - could you please point me where exactly the spec describes this behaviour? The only mention of offline tokens is in Section 2.7. Back-Channel Logout Actions, and as far as I read it, there is no mention that logout of an offline session should log out an online session as well. The only sentence touching a bit the topic there is "The RP then clears any state associated with the identified session(s)." However, it does not follow that the identified session of the offline session would also be the online session.

Exactly that part. The point being, we do not destroy offline sessions when logging out online. And that is OK according to the specs. The handling of offline sessions is a question mark, and we decided for whatever reason to do it that way.

FYI, I also think both session types should be treated independently. But I'm not yet following why you are concerned about both sharing the same id if that will not really fix the "inconsistency".

[Hynek Mlnarik]

Thanks Pedro.

On Wed, Mar 31, 2021 at 3:30 PM Pedro Igor Craveiro e Silva <pigor.c...@gmail.com> wrote:

On Wed, Mar 31, 2021 at 8:25 AM Hynek Mlnarik <hmln...@redhat.com> wrote:

I still would like to understand the reasons why the current implementation behaves as it does. Any pointers to discussions would be much appreciated. So far it seems to me that the inconsistency is should have never been there.

I don't know all the motivation behind the current implementation. AFAIK, it has been there for a long time.

The only inconsistency I can see is the fact that we are using logout to destroy offline sessions. And that is the reason why I mentioned the misconception around offline sessions.  

That said, none of the options you gave to achieve consistency makes sense for me. The core issue (and a conceptual one, IMO) is offline sessions treated like online sessions a 

nd their usage in the logout endpoint.

That's exactly the point - they are treated differently upon logout. The inconsistency is that offline session logout logs out also online session, while online session logout logs out only itself even if an offline session is there.

You raise an interesting point. Why should they be not treated in the same way? I take it is not per spec (though the logout endpoint is keycloak-specific either) but allowing revocation of offline tokens via logout endpoint does not seem to be a violation of the Logout Endpoint spec either?

 

The fact we destroy online when "logging out" offline is our interpretation, probably motivated by some use case. And I don't see how to make that consistency without dropping offline sessions from the logout endpoint.

I am onboard with the idea with dropping offline sessions off the logout endpoint, if that is possible, and only revoking the offline sessions from the account / admin console.

Ad spec - could you please point me where exactly the spec describes this behaviour? The only mention of offline tokens is in Section 2.7. Back-Channel Logout Actions, and as far as I read it, there is no mention that logout of an offline session should log out an online session as well. The only sentence touching a bit the topic there is "The RP then clears any state associated with the identified session(s)." However, it does not follow that the identified session of the offline session would also be the online session.

Exactly that part. The point being, we do not destroy offline sessions when logging out online. And that is OK according to the specs. The handling of offline sessions is a question mark, and we decided for whatever reason to do it that way.

I am looking for exactly this reason :-)

 

FYI, I also think both session types should be treated independently. But I'm not yet following why you are concerned about both sharing the same id if that will not really fix the "inconsistency".

I think we're on the same page here. My concern is not about sharing the same ID, this seems just to be a shortcut taken in the past. The question I am raising is about why do we maintain the connection between the online and offline session and whether this connection is even needed.

[Schuster Sebastian (IOC/PAU1)]

Hi Hynek,

 

I think the spec does not even know about offline sessions. It only knows about sessions and offline tokens which might have been generated as part of a session. The differentiation between sessions and offline sessions is a Keycloak-specific

implementation choice. If the spec says, “RP then clears any state associated with the identified session”, that can only refer to the normal session. IMHO, the offline session is associated with the online session anyways, they even use the same session identifier.

So for me, it makes perfect sense to always logout normal sessions and optionally also remove offline sessions.

 

Best regards,

Sebastian

 

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Project Delivery Berlin 22 (IOC/PDL22)
Bosch.IO GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch.io
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Threema / Threema Work: MF9VMEAE | Sebastian...@bosch.io

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAMvXD%3DEQuedOBF70kCmpWkXgaS9C2UAhZ_489dMpmuqYeX4g9g%40mail.gmail.com.

[Hynek Mlnarik]

Hi Sebastian, thank you.

On Thu, Apr 1, 2021 at 9:12 AM Schuster Sebastian (IOC/PAU1) <Sebastian...@bosch.io> wrote:

Hi Hynek,

 

I think the spec does not even know about offline sessions. It only knows about sessions and offline tokens which might have been generated as part of a session. The differentiation between sessions and offline sessions is a Keycloak-specific

implementation choice.

Precisely

 

If the spec says, “RP then clears any state associated with the identified session”, that can only refer to the normal session. IMHO, the offline session is associated with the online session anyways, they even use the same session identifier. 

So for me, it makes perfect sense to always logout normal sessions and optionally also remove offline sessions.

Following the logic, if "offline session is associated with the online session" (i.e. they are associated with each other), then from "RP then clears any state associated with the identified session" it follows that regardless of which session is being logged off, both would need to be revoked (as both are associated with the other). Obviously, this would be against the purpose of the offline sessions and I'm not arguing for changing the behaviour in this regard. But here it is where the inconsistent treatment of offline and online sessions originates.

As for "they even use the same session identifier." - this has been a choice of the original implementor and it might or might not have been the right decision at that time. [*] Having the same ID has been a consequence of rather than reason for the logout behaviour. Still, perhaps knowing the reason for that could help understand reasons for the logout behaviour as well.

My question thus is: What is the rationale for logging out an online session when the corresponding offline session is logged off? In other words, why are they not treated independently?

Best,

--Hynek

[*] For what is worth, in the new store, the identifiers of online and offline sessions will be different.

[Pedro Igor Craveiro e Silva]

On Wed, Mar 31, 2021 at 1:24 PM Hynek Mlnarik <hmln...@redhat.com> wrote:

Thanks Pedro.

On Wed, Mar 31, 2021 at 3:30 PM Pedro Igor Craveiro e Silva <pigor.c...@gmail.com> wrote:

On Wed, Mar 31, 2021 at 8:25 AM Hynek Mlnarik <hmln...@redhat.com> wrote:

I still would like to understand the reasons why the current implementation behaves as it does. Any pointers to discussions would be much appreciated. So far it seems to me that the inconsistency is should have never been there.

I don't know all the motivation behind the current implementation. AFAIK, it has been there for a long time.

The only inconsistency I can see is the fact that we are using logout to destroy offline sessions. And that is the reason why I mentioned the misconception around offline sessions.  

That said, none of the options you gave to achieve consistency makes sense for me. The core issue (and a conceptual one, IMO) is offline sessions treated like online sessions a 

nd their usage in the logout endpoint.

That's exactly the point - they are treated differently upon logout. The inconsistency is that offline session logout logs out also online session, while online session logout logs out only itself even if an offline session is there.

As I mentioned before, there is no inconsistency here but how we implemented logout for offline sessions to also logout online. As mentioned too, the other way around is fine and backed by the spec.

 

You raise an interesting point. Why should they be not treated in the same way? I take it is not per spec (though the logout endpoint is keycloak-specific either) but allowing revocation of offline tokens via logout endpoint does not seem to be a violation of the Logout Endpoint spec either?

As mentioned before, the spec do not cover logout for offline sessions. And the open question there is there for a reason: online and offline are different things. We can't treat them equaly.

You mentioned "revocation of offline session via logout endpoint". Instead, consider using the token revocation endpoint for revocation.

Keep in mind that the use case for offline tokens is to allow clients to act on behalf of users even though they are not logged in.

At the logout endpoint, you can do both GET and POST. GET does not make sense at all in a standard use case for offline. The POST is pretty much token revocation (implemented I think before the introduction of token revocation).

 

 

The fact we destroy online when "logging out" offline is our interpretation, probably motivated by some use case. And I don't see how to make that consistency without dropping offline sessions from the logout endpoint.

I am onboard with the idea with dropping offline sessions off the logout endpoint, if that is possible, and only revoking the offline sessions from the account / admin console.

And token revocation endpoint, as it stands today.

 

Ad spec - could you please point me where exactly the spec describes this behaviour? The only mention of offline tokens is in Section 2.7. Back-Channel Logout Actions, and as far as I read it, there is no mention that logout of an offline session should log out an online session as well. The only sentence touching a bit the topic there is "The RP then clears any state associated with the identified session(s)." However, it does not follow that the identified session of the offline session would also be the online session.

Exactly that part. The point being, we do not destroy offline sessions when logging out online. And that is OK according to the specs. The handling of offline sessions is a question mark, and we decided for whatever reason to do it that way.

I am looking for exactly this reason :-)

I gave one actually, the misconception of treating offline like online.

The other could be legacy behavior due to the lack of token revocation.

 

 

FYI, I also think both session types should be treated independently. But I'm not yet following why you are concerned about both sharing the same id if that will not really fix the "inconsistency".

I think we're on the same page here. My concern is not about sharing the same ID, this seems just to be a shortcut taken in the past. The question I am raising is about why do we maintain the connection between the online and offline session and whether this connection is even needed.

Don't know, but I have no issue with this "connection" between the two types of sessions, as it stands today in logout. And for me it makes more sense than b) and c) you proposed.

To summarize, the improvement here IMO would be to drop offline from logout. But that should not happen any time soon.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAMvXD%3DFuDQHZJBYZfKPcMHwsqTXk4kxU2NdNDYrBCksw-tgUdg%40mail.gmail.com.

[Schuster Sebastian (IOC/PAU1)]

Hi Hynek,

 

I can at least give you some insight into our use case. We federate Keycloak with an external IDP. When the user changes its password there, the requirement is to log out the user everywhere, since the reason might be his password got compromised.

Since the external IDP does not know whether offline sessions are involved at Keycloak, he can only trigger one backchannel logout request. And this one should in effect basically invalidate everything in our case, sessions and offline tokens.

 

Best regards,

Sebastian

 

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Project Delivery Berlin 22 (IOC/PDL22)
Bosch.IO GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch.io
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Threema / Threema Work: MF9VMEAE | Sebastian...@bosch.io

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

 

[Pedro Igor Craveiro e Silva]

On Thu, Apr 1, 2021 at 7:53 AM Schuster Sebastian (IOC/PAU1) <Sebastian...@bosch.io> wrote:

Hi Hynek,

 

I can at least give you some insight into our use case. We federate Keycloak with an external IDP. When the user changes its password there, the requirement is to log out the user everywhere, since the reason might be his password got compromised.

Since the external IDP does not know whether offline sessions are involved at Keycloak, he can only trigger one backchannel logout request. And this one should in effect basically invalidate everything in our case, sessions and offline tokens.

For brokering that makes sense, where the user is within the boundaries of a different security domain.

However, considering a similar use case but without brokering, changing passwords should effectively invalidate sessions. Not sure about offline though. If we are not invaliding offline in this case, I think this is not good.

[Marek Posolda]

Hi Hynek and others,

Few points to this:

- The reason why during login there are both online and offline session is the SSO browser session. Due to this, every offline session is usually somehow tight to some "online" session, which was used for browser SSO login (with the exception of non-browser cases like OAuth2 Resource Owner Password Credentials Grant).

- I think there is some history for the current behaviour. When we added initial support for offline tokens:
-- we did not yet have revocation endpoint as Pedro mentioned
-- there were not any OIDC logout specifications yet (even drafts)
-- we were focused a lot on our Keycloak adapters.

- With regards to the logout triggered from adapters: when there is a call to "httpServletRequest.logout()", the adapter calls Keycloak backchannel logout endpoint with the refresh token ( LogoutEndpoint.logoutToken()). When the refresh token can be also offline token. As adapter currently expects this to kill also browser SSO session, it means that calling LogoutEndpoint with the refresh token (or offline token) always kills the "online" session if it exists. And just in case it is offline token, then also it kills offline session.

How to change this behaviour? I can imagine possibilities like this:

1) Revocation of offline session will be possible just with calling revocation endpoint OR with the account/admin console. But it won't be possible with calling LogoutEndpoint.logoutToken() . Invocation of this endpoint with offline token can show the error like "Logout SSO session with offline token not supported. Please use revocation endpoint to revoke offline session"

2) Calling LogoutEndpoint.logoutToken() with offline token will revoke just the offline session, but not the online session. When called with refresh token, it will revoke just the online sessions

3) Stick to current behaviour. Improve things once we have a plan for proper support around OIDC logout specifications. AFAIK OIDC Backchannel logout has special "Logout Token" and has much more flexibility around the logout based on the content of the token (EG. logout single session or fully logout user, logout online or offline session based on the flags in the logout token etc).

Regarding backwards compatibility, there are those possible changes:
- LogoutEndpoint won't work with offline token. This will be the case if we go with (1)
- Calling "httpServletRequest.logout()" from adapters won't kill SSO session when called with offline token. This will be the case if we go with (1) or (2). So for those cases, we will need to document that SSO logout will work just with the "online" refresh token. Hence applications will need to stick with it and make sure that they never call logout endpoint with offline token, but always with "online" token.

My preference is to go with (3), but I am fine with (1) or (2) as well (or something else?). We may just need to make sure that all backwards incompatible changes are properly documented.

Marek

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAMvXD%3DFGv1uEwzkj94%2BwucX1k-NetjehHyopMvCNwkvTCNX7Eg%40mail.gmail.com.

[Hynek Mlnarik]

Hi Marek,

Thank you for all the information. This explains the rationale behind the current behaviour, and even though the offline token handling in logout endpoint is not ideal, I also do not see an easy and fast way out.

The proposal 1 seems to me to be the right one long-term, once the standard logout endpoint is properly implemented. On top of that, I'd even be in favor of removal of the Keycloak proprietary logout endpoint then. However for the time being, we need to stick with the current behaviour. Any solution thus should also allow for a transition period where the logout endpoint would behave as it is now.

This means that the associations between online and offline sessions need to be maintained for the time being. To ease the transition, it would be better to keep the association loose. (Currently it is tightly coupled via sameness of the IDs which does not work for the new store.) I got a suggestion from Stian to store the associated session ID in the session notes, and I am in favor of this suggestion: once the transition is over, it is easy to locate and remove the logic dealing with this particular note.

--Hynek

[Marek Posolda]

+1 to everything you mentioned.

Marek