# More secure logout redirection **URL:** \ **Category:** Feature\ **Tags:** sso, discourseconnect\ **Created:** [May 14, 2015, 2:37am UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795 "2015-05-14T02:37:59Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![erik](https://avatars.discourse-cdn.com/v4/letter/e/b5ac83/32.png) [@erik](https://meta.discourse.org/u/erik)\ **Post date:** [May 14, 2015, 2:37am UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795/1 "2015-05-14T02:37:59Z")
I want the user’s session in my SSO provider to be killed when a user clicks ‘Log Out’, but the current logout redirection feature doesn’t quite fit the bill because I have no way of knowing if the ensuing GET to the logout page was intentional or the result of a low-effort CSRF. (I do consider drive-by logouts from my provider to be a security problem.) From the perspective of the SSO provider (on the server), I want to authenticate that the user has _deliberately_ ended their Discourse session. There are two approaches that come to mind: 1. Add a SSO Secret-signed bearer proof to the URL the user is redirected to. 2. Allow the SSO provider to query Discourse for the liveness of the user’s session. My instinct is that the first approach is complicated to get right. The second might be _really_ easy, depending on how Discourse stores sessions. (I haven’t looked.) Ideally, I could just hit an (authenticated) admin API endpoint with the nonce from the login and find out of the session created from that nonce is alive. ---
**Author:** ![Peter\_Backgren](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/peter_backgren/32/66263_2.png) [@Peter\_Backgren](https://meta.discourse.org/u/Peter_Backgren)\ **Post date:** [November 15, 2015, 2:04pm UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795/2 "2015-11-15T14:04:33Z")
The first approach is the one that “feels” right though. Like, if you get the “user id” you provided during first signup back using the SSO Secret you don’t need much more. ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [November 15, 2015, 7:19pm UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795/3 "2015-11-15T19:19:53Z")
we would need to use an OTP + user id encrypted using sso key to get this done that way I am not against it but lots of work An “is logged in” is much easier to solve especially if “log out strict” is on ---
**Author:** ![Peter\_Backgren](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/peter_backgren/32/66263_2.png) [@Peter\_Backgren](https://meta.discourse.org/u/Peter_Backgren)\ **Post date:** [November 19, 2015, 1:55pm UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795/4 "2015-11-19T13:55:36Z")
Or you could let the sso provider take the responsibility? When logging in you also get a ,logouturl=[http://mysso/logout.aspx?mypayload=xyz](http://mysso/logout.aspx?mypayload=xyz) in the sso package. It’s then up to the provider to decide how he want’s it implemented. If non-secure a userid in his return url could suffice for him logouturl=[http://mysso/logout.aspx?uid=46732](http://mysso/logout.aspx?uid=46732) If encrypted wityh the same secret it could be logouturl=[http://mysso/logout.aspx?sso=xxxxxxx](http://mysso/logout.aspx?sso=xxxxxxx) and up to him if there is a userid or perhaps even login datetime information. But he has already encrypted the sso part when giving it to you so he could even use another secret if he wants. You just return using what was given. I don’t even think there would be a reason to add some expiry datetime info in your direction, just return the stuff if you can catch the logout. ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [November 19, 2015, 10:33pm UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795/5 "2015-11-19T22:33:05Z")
> [@Peter\_Backgren](#): > > But he has already encrypted The point here is avoiding replay attacks somehow… just encrypting will allow “hackers” to replay a logout. ---
**Author:** ![Peter\_Backgren](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/peter_backgren/32/66263_2.png) [@Peter\_Backgren](https://meta.discourse.org/u/Peter_Backgren)\ **Post date:** [November 23, 2015, 11:16am UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795/6 "2015-11-23T11:16:34Z")
Replaying a logout is more of a nuisance than anything else. Letting the sso provider take the responsibility also meant possible security measures would be taken at that end, at their option. But ok, why give any possibilities. ---
**Author:** ![chapoi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chapoi/32/537252_2.png) [@chapoi](https://meta.discourse.org/u/chapoi)\ **Post date:** [December 4, 2025, 11:35am UTC](https://meta.discourse.org/t/more-secure-logout-redirection/28795/7 "2025-12-04T11:35:55Z")