Revoking specific login sessions

Looking to implement a way to log all other sessions (sessions that are not the currently connected user). You’ve probably seen this security feature in other web apps, something like:
(ip address is blacked)

I am using Hydra for first party app
I can use the api to invalidate all login sessions of a certain user:

But cannot get login sessions for certain subject afaik?

Any way to work around this ?

More use cases:
Log out all other sessions after password reset, email login change etc

1 Like

What do you mean by that? Are you looking to invalidate the sessions at your RP (Relying Party / OAuth2 Client) or in Hydra?


I am using Hydra for first party app.
I do not manage a session, I rely on Hydra for that. So you can say the access/refresh tokens hold the session.

Therefor, to invalidate other sessions for a user, I need to invalidate all other access tokens.

There’s an api to delete all login sessions for a specific subject:

DELETE /oauth2/auth/sessions/login?subject=string

Maybe need an api to get all login session for a subject

GET /oauth2/auth/sessions/login?subject=string

So that I can delete specific ones:

DELETE /oauth2/auth/sessions/login/{id}

Or something of that sort.

I am not sure if that is something you consider in Hydra’s scope or not. I think the use case is valid, it is common to log out all other connected users in password reset flows. But the use oh Hydra for first party app is less common I guess.

Another work around is to bypass Hydra’s api and do it directly on Hydra’s database

I see, I believe we could add the invalidation of specific session ids with DELETE /oauth2/auth/sessions/login?sid=string. How would you differentiate between the different SIDs though?

I would need to first GET all login sessions for a subject. I would need that so I could show all the active login sessions for the subject and possibly revoke each one individually.

Currently there’s no GET all login sessions, there’s one for consent sessions though:

GET /oauth2/auth/sessions/consent?subject=string

Revoking “all others” would require to iterate and make the http call in a loop.

How would you contextualize those sessions? We are currently not storing any additional information (e.g. User Agent). You would maybe need to do that in the login app, where you get the sid, and store that sid with additional info (e.g. user agent, ip, …)?

This is in fact a good use case to transport over to ORY Kratos. We’ve already added some stub info to the session (user agent, ip, …).

However I do get the need for both of those API endpoints, I think it makes sense to add them and it should actually not be too much work if I’m not mistaken.

I think I was confusing between login sessions and the oauth tokens (access/refresh)

I see that accept login request endpoint accepts context object:

  "acr": "string",
  "context": {
    "property1": {},
    "property2": {}
  "force_subject_identifier": "string",
  "remember": true,
  "remember_for": 0,
  "subject": "string"

But that is not related to the oidc tokens and doesn’t carry over to the token’s accessTokenExtra which I can get on token introspection.

The login session “invalidate all” endpoint clearly says:

This endpoint does not invalidate any tokens and does not work with OpenID Connect Front- or Back-channel logout.

Therefor, as for my understanding, it will not really log out anyone already holding an access / refresh token, their tokens will still be valid.

What I need is a way to invalidate access tokens for specific sub or username properties of the access token. This is discussed in here:

Sounds awesome!

looking for the same answer.
After reset password, I want to invalidate all access/refresh_token for a specific user.

Please do not use access tokens as proof of authentication. Revoking an access token is not the same as deleting a user session. It is simply not the same thing. Don’t do it.

What you want is probably revoking access for a specific oauth2 application (think of GitHub 3rd Party Apps or Google 3rd Party Apps etc):

Again, this has absolutely nothing to do with login.