Hello all, We a struggling with some logout / session management related issues with our CAS OAuth clients. We are using CAS 5.0 and have use cases, where on CAS logout, the OAuth access tokens of a user would need to be removed, but only tokens granted for that specific SSO session. The current use case is related to a service which uses the implicit grant flow to authenticate users. Technically, as far as I understand, we would need to link access tokens to SSO sessions (CAS doesn't seem to link the tokens in such a way), so that on SLO, the access tokens granted for the SSO session could be revoked.
I understood that the SLO functionality is really not supported for the OAuth protocol and I haven't found a way to handle this in CAS. Thus, we are thinking about creating some external service, which could keep track of SSO sessions and related access tokens, and then revoke the access tokens when receiving SLO notification from CAS. So I looked into the SLO notification functionality (back-channel), and seems like at least in the implicit grant case, the notification contains the Service Ticket ID that was granted as part of the authentication flow. Next problem is, that of course our external service has not received such identifier in the login process and possibly the flow would need to be changed to transmit this ID to the client (possible in the same redirect request with the access token?). Hopefully you get the picture of what we're attempting. The goal would be to invalidate access tokens for a specific SSO session, but still keep access tokens for possible other sessions of the same user (otherwise we could just remove all tokens). A few questions: * Are we doing something completely wrong here? Maybe this is not the way to handle SSO sessions and OAuth access at all? Could there be some other ways of looking at the problem at hand? * Is the approach of modifying the authentication flows (authorization code grant or implicit grant) in such a way that our external service would have some handle to the SSO session, meaningful at all? The service would then hold a list: "ST-123": ["AT-1", "AT-2", "AT-3"...]. Or is it actually the TGT that we should be able to transfer to the service on login, and also deliver the same TGT on SLO notification? Somehow this feels wrong. There are also a few issues, which may be bugs, related to this: * The logoutUrl setting of a service configuration doesn't seem to propagate, we always have logoutUrl pointing to the service URL of the callbackAuthorize service. * All access tokens seem to have a service mapping to the callbackAuthorize -service. Is this by design? So we can not know which service an access token has actually been granted for (unless searching for it based on the client ID in the callbackAuthorize service URL) Thanks for any ideas! Tom -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ca8c5c5f-dfff-4f16-8086-e1f10c2d3f0e%40apereo.org.
