OpenId Connect integration

[Akasch]

I see caching for the Auth-Tokens: is it checked to revoke the tokens if the user changes his password or perform a logout on the central SSO?

[ftsell]

I see caching for the Auth-Tokens: is it checked to revoke the tokens if the user changes his password or perform a logout on the central SSO?

Those are tokens not issued for a user but to the application itself (sometimes its called service account authentication). There is no user involved who can change their password.

[Akasch]

I haven't looked into it, but i quit often see that a logout on the central SSO platform or a password change there does not invalidate active sessions in the applications that have an ongoing session for the user. This leads to the problem if the User has the password stolen and the attacker was authenticated he can not invalidate existing sessions.

[timonegk]

As Finn said, the caching here is only about bitpoll's token required to request the users in a group.

However, your point about SSO login is probably still valid. @ftsell do you know how we handle that or if we should change something in the simple_openid_connect library to make sure that a token is still valid?

[ftsell]

However, your point about SSO login is probably still valid. @ftsell do you know how we handle that or if we should change something in the simple_openid_connect library to make sure that a token is still valid?

Hmm good question :thinking: I haven't verified this extensively but what I think is happening is that the mechanism here is two-fold:

• The identity provider may send an application a logout notification whenever it chooses e.g. when a user changes their password. This is entirely up to the idp though and I don't know if keycloak sends those logout notifications when a user changes their password. The receival of these notifications is implemented in simple_openid_connect (technically only for frontchannel logout notifications) but also needs to be configured in keycloak.
• The access tokens handed out from keycloak are intentionally short lived and if a session is invalid, the retrieval of a new access token from the long-lived refresh token does not succeed. This is currently not validated at all in simple_openid_connect and yes, I think we should implement it. I have created a corresponding issue: https://github.com/fsinfuhh/py_simple_openid_connect/issues/10