Revoke OAuth2 Token For Mobile App

Question

When a user logs into my mobile app it uses OAuth to authenticate them and generates a token. The token is then checked against each subsequent request. Each user account in my application has an active flag. When I deactivate an account I set this flag to False which is checked on login, if False the user will not be able to login and will not receive an authentication token.

However, I have to cover the scenario where a mobile device could be misplaced while the user still has a valid token. So someone who should not see data now has access to it. I can deactivate the user account but with an existing valid token the user would still be able to use the app until it expires.

Is there a way to force token expiration for a certain user? Do I have to store the tokens in a database to be able to achieve this?

Answer 1

You cannot force token expiration. Tokens expire when its lifetime (determined when constructed) has passed.

You can distribute a blacklist to the points in your system where they are checked (eg api server for remote resource or the app for a local resource) to enable you to revoke them. If your token contains the userId you can distribute a blacklist of userIds and just check if it is on the blacklist. If your tokens do not contain some kind of identifier you have to store the tokens you issue for each user until they expire and distribute a blacklist of tokens.

You could also choose to give your tokens a very short livetime and just wait for them to expire.

Answer 2

The OAuth2 standard defines another approach to this problem, and that is to use the token revocation and token introspection endpoints.

The revocation endpoint is described in RFC 7009, e.g.

This revocation mechanism allows a client to invalidate its tokens if the end-user logs out, changes identity, or uninstalls the respective application.

The introspection endpoint is described in RFC 7662, e.g.

This specification defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata for a given token that was presented to them by an OAuth 2.0 client. This metadata includes whether or not the token is currently active (or if it has expired or otherwise been revoked)

But, yes, this probably implies storing the tokens (or a reference to them) in a database somewhere. It might also mean that you don't need to use JWTs but can instead use opaque reference tokens. Here's a good post on the trade-offs, e.g.:

Reference tokens (sometimes also called opaque tokens) on the other hand are just identifiers for a token stored on the token service. The token service stores the contents of the token in some data store, associates it with an infeasible-to-guess id and passes the id back to the client. The recipient then needs to open a back-channel to the token service, send the token to a validation endpoint, and if valid, retrieves the contents as the response.

A nice feature of reference tokens is that you have much more control over their lifetime. Where a self-contained token is hard to revoke before its expiration time, a reference token only lives as long as it exists in the STS data store.