More secure logout redirection

feature
,
1

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.

3 Likes
2

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.

3

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

1 Like
4

Or you could let the sso provider take the responsibility?

When logging in you also get a ,logouturl=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

If encrypted wityh the same secret it could be
logouturl=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.

1 Like
5

The point here is avoiding replay attacks somehow… just encrypting will allow “hackers” to replay a logout.

6

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.