How to revoke all the tokens for a user when they change their password with Jersey and OAuth2

0
votes

There is a requirement in our application: When users change their password, all other logins (from other devices or computers) should be re-authenticated (except for the current user's session).

I read below (link provided below and cited the paragraph which is relevant) and got the idea: revoke all the tokens for a user.
But Not sure how to implement this (revoke all tokens). We are using Jersey and OAuth2. Does revoking tokens means remove existing access token/refresh token from session and cookie. Then replace with new tokens?

Thanks

[Best practice for REST token-based authentication with JAX-RS and Jersey] Best practice for REST token-based authentication with JAX-RS and Jersey

Handling token revocation with JWT

If you want to revoke tokens, you must keep the track of them. You don't need to store the whole token on server side, store only the token identifier (that must be unique) and some metadata if you need. For the token identifier you could use UUID.

The jti claim should be used to store the token identifier on the token. When validating the token, ensure that it has not been revoked by checking the value of the jti claim against the token identifiers you have on server side.

For security purposes, revoke all the tokens for a user when they change their password.

1
securityoauth-2.0jerseytoken

1 Answers

1
votes

In general (not only with Jersey), you have to invalidate all tokens generated for a user when change their password.

But Not sure how to implement this (revoke all tokens)

That means that you have to expire every issued token in your oauth-server database for that user:

  • relational DBs: a batch update.
  • noSQL: a single remove of the reference.
  • Redis or similiar, a force evict.

Does revoking tokens means remove existing access token/refresh token from session and cookie. Then replace with new tokens?

Sort of, revoking means:

  • expire (not necesary remove) all issued tokens from database.
  • the session and cookies must be aware of this and to be removed or marked as expired when you detect it (usually a tricky part).

Then replace with new tokens?

In most cases, after this, when a user want to access a protected resource, your security filter/layer must:

  • redirect to the login page through the oauth2 server (the re-authentication part).
  • or return an access_denied error (in the case of services, APIs)