I've seen couple of talks which suggested usage of OAuth token translation at the API gateway from opaque token to JWT token. What are the advantages and disadvantages of this approach, who should use it?

If we are using HTTPS I don't think this makes any difference in terms of token leakage. Two disadvantages would be now clients can't deduce what they can do or if their token still active, and we must put all our API behind a gateway*.

*: I mean we could also put them behind n gateways as long as they talk to a single Authorization Server, but this puts n times the load to the AS.

Here is one example talk https://youtu.be/BdKmZ7mPNns?t=901


1 Answer 1


One remark on that:

now clients can't deduce what they can do or if their token still active

The safest way to store the JWT is probably in a httponly (to prevent XSS) secure cookie (+ take measures against XSRF). If you do that, client-side code can't directly check the JWT anyway.

As for your initial question, I guess it can help give more control over revocation / session expiration. If you hand out the JWT to the end user, you are powerless until "exp" is reached (and this parameter has been decided by the issuer, which might not align with your own policies). With the opaque identifier, you keep control and can revocate access anytime. In a way, you keep old fashion session management while still leveraging JWT for delegated authentication.


Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens.


For a stateful service, you hand out a new short-lived, single-use token for each service - which is then exchanged on the service itself, for a session on that specific service. You never use the token itself as the session.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .