5

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

EralpB
  • 358
  • 3
  • 11
  • https://www.slideshare.net/opencredo/authentication-in-microservice-systems-david-borsos/ This slide explains why a translation in the gateway. – jayven May 14 '17 at 08:59
  • [The video of the slide above](https://www.youtube.com/watch?v=SemWSxmkomY) – Sisir Jun 26 '19 at 19:35

1 Answers1

4

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.

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

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.

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

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.

Mathieu Rey
  • 158
  • 5