JSON Web Token expiration

Question

On most of the JWT (JSON Web Token) tutorial (e.g: this and this) are saying, once validated you can use the incoming token to get client information without validating it from

Answer 1

It's difficult to revoke JWT-based access tokens if not impossible.

How should an access token be represented? There are two major ways.

1. As a meaningless random string. Information associated with an access token is stored in a database table behind an authorization server.
2. As a self-contained string which is a result of encoding access token information by base64url or something similar.

A choice between these ways will lead to consequent differences as described in the following table.

See "7. Access Token" in "Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings" for pros and cons of the ways of access token representation.

If your access tokens are JWT-based, your system has to (1) remember revoked access tokens until they expire. Another compromise is to (2) make lifetime of access tokens short enough and give up revoking them.

Personally, after consideration, I didn't select JWT as access token representation when I implemented an authorization server (Authlete) because it is difficult/impossible to revoke and update JWT-based access tokens once they are issued.

Answer 2

That's the main problem when you are using JWT. So basically best approach in this case is creating blacklist on your gateway. It's not best solution for security point of view but this is only good solution if you are using JWT.

Answer 3

RFC 7009 specifies OAuth 2.0 Token Revocation. Basically you have an endpoint where you can revoke the access_tokens.

Answer 4

It's not clear which OAuth flow you are using from your question, or whether you are referring to OpenID Connect rather than Oauth.

Consider using refresh tokens and have a much shorter expiration on your access token - e.g. 30 mins.

In this scenario, the user (resource owner) doesn't have to keep authenticating, and your API (Resource Server) doesn't have to check the user is still valid on every single request.

Once the access token expires, your client (application calling your API) should contact your DB (Authorisation Server) and exchange its refresh token for a new access token - and usually a new refresh token - providing the user is still a valid user on your DB and the user has not revoked access for the client application to his/her data on the API.

You could also use token revocation as suggested in another answer if your Authorization Server allows it but I would try refresh tokens and short-lived access tokens as it's much easier to implement and doesn't pollute your API with user authentication/authorisation concerns - this job is best done by an Auth Server.