[Logout] How to logout from provider?

[cocoon]

I am unsure if this is an issue or not.

How can I tell rauthy to logout a user from it's provider if logging out from rauthy?

Currently rauthy seems not to call the end session endpoint or any configuration for it?

I read the book about the user logout options, but did not understand if it can be done:
https://sebadob.github.io/rauthy/work/logout.html?highlight=logout#user-initiated-logout

I am using ADFS as provider and there are these options to logout, and I would have expected to see a call to the "end_session_endpoint", but it currently seems not to do it (v0.29.3)?

https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-logout-openid-connect

there are multiple ways to logout from ADFS:

"end_session_endpoint":"https://fs.fabidentity.com/adfs/oauth2/logout",

or:

https://fs.fabidentity.com/adfs/ls/?wa=wsignout1.0

GET https://<server-name>/adfs/ls/?wa=wsignoutcleanup1.0&id_token_hint=<current_Id_Token>&post_logout_redirect_uri=http://localhost:5000 HTTP/1.1

[sebadob]

How can I tell rauthy to logout a user from it's provider if logging out from rauthy?

Currently, you can't.

Rauthy can accept Backchannel Logout from upstream providers and propagate them to downstream clients, but it does not trigger a logout upstream. This is also not as straight forward as you might think, since this can very easily get you into a situation with endless loops and you DDoSing yourself, your upstream and all clients.

For instance, if Rauthy would simply trigger an additional upstream logout now, this self-DDoSing would happen. Making this work is not simple at all. If you just have a single upstream provider, it can be done if Rauthy would actually save the id_token from upstream and instead of actually logging you out, it would need to do nothing at all but only send this logout to upstream. The upstream provider then would trigger the backchannel logout to Rauthy again and everything would work normally.

The issue is, that this will most probably not work reliably. To be able to log out upstream, you need a valid id_token and if you don't have one, nothing will happen, in quite a few cases even silently. This means upstream would not trigger the backchannel logout and simply nothing would happen, if the id_token has expired, which will we be the case in most situations. So, to solve this, Rauthy would need to do a lot of extra work and always renew the id_token from upstream even if it does not even care about it at all after the initial login. This means we would not only need to save id_tokens for each user logged in via upstream, but also refresh_tokens and constantly renew them only to maybe trigger a logout against upstream.

The next issue is, when you have multiple upstream providers. Some support backchannel logout, other don't. You of course need to track the data and state for all of them, and renew tokens for all of them, even if you don't need them at all.

You could maybe do a front channel redirect in that case so the user has to click logout on the upstream provider with a possibly existing session in the browser, but even that might not work and the user would end up in a very weird place, if it fails.

Another solution might be to do all of this additional overhead work, save all tokens and renew them constantly, and then on logout, do the logout like it works now, and in addition send one to upstream. This would, on success, trigger this whole chain twice, if you add some additional checks in the chain and don't forward logouts to upstream again, if they came from upstream already.

---

All of this is possible, but a huge amount of work, additionally used resources 24/7, and not implemented at all so far.

[cocoon]

This is also not as straight forward as you might think

Indeed, thank you very much for this detailed response.
Of course I was totally expecting that this case is totally an OIDC standard thing and just needs another call and done.

when you have multiple upstream providers

So here I thought it would be an option in the provider. And (currently) a user can only be mapped to one provider.

Like adding a post_logout_url for rauthy but configured in the provider and if specified a button will be visible with "Provider logout", logging out of rauthy and after logout from rauthy redirect to the given provider logout url. Of course it would get complicated if it would need POST with variables and if providers would need manual stuff, for ADFS it looks easy as it is a simple GET, and I thought it would be defined in the OIDC standard anyhow.

But I don't have the full "picture" of the flow and it's my very early days with the whole topic. So thanks for the insights, appreciated a lot!

[sebadob]

Of course I was totally expecting that this case is totally an OIDC standard thing and just needs another call and done.

Yes, it can be this simple, if everything lines up nicely.

I think Backchannel Logout has limited use cases. If you want to use it on a regular basis, it only makes much sense if you are using JWT Tokens for ongoing authn/authz when accessing your downstream clients. In this case, you handle token refreshes anyway already and you will either be able to actually do the logout with an active id_token, or your tokens have expired anyway already. But even then, depending on your configuration, your session on Rauthy might still be active. However, I don't think, that ongoing authn/authz via JWT tokens is a good practice, even though it's pretty simple to implement. They are less secure than sessions, because they cannot be revoked, and you need to send quite a lot of additional data with each single request.

Generally, you want to have short sessions on upstream providers all the time, or you are using Rauthy in a way that you use passkeys and request a new auth with each login anyway, which is the most secure setup. Providing the passkey for each login takes like 3 seconds each time and is no big issue at all. It's even faster than using auto-fill from a password manager most of the time. In this case, it does not make any difference, if your Rauthy session (or further upstream) is still active, since you need to re-authenticate for each client anyway.

However, I don't use JWT tokens for ongoing authn/authz anywhere. I only use them to establish real sessions downstream, because they provide a lot more security and can be revoked at any point in time, which tokens cannot by design. In this case, you won't keep refreshing id_tokens and therefore you are not able to use backchannel logout as your normal logout procedure, but you rather just invalidate the session on the specific client. This cannot fail and does not need any additional overhead in resources and storage.

The real use case for backchannel logout imho is when you want to force-logout a user on all clients, no matter what. For instance, if you have a time-limited user, or someone leaves a company and must be logged out of any possible client. Or for some other reason why you want to log someout out of all clients. SCIM in addition will take care of full user deletions and updates.

---

It's the same as always. "It's pretty straight forward, but / until / however / ...".

The end_session_endpoint on your ADFS is the same as for Rauthy, but yes, it needs an authenticated request, like defined in the corresponding RFC. At least the id_token_hint must exist and contain a valid token and if you depend on this to succeed, you would need to do a lot of additional work to make sure it either cannot fail, or you have a fallback method how you handle logouts.