Continue using JWT as access tokens?

[aeneasr]

JWTs as access token are great, because we can retrieve important information like subject or issuer by simply decoding the access token without "tough" crypto methods. Additionally, we can verify that the access token is valid by checking the signature against Hydra's public key.

JWTs as access tokens are bad, because they bloat every request by about 8-9 times. Dropbox uses access tokens with 64 characters, JWTs tend to be around 550 characters.

Please feel free to state your opinions on this matter here. A viable option could be to provide different strategies and select one through an environment variable.

[bketelsen]

JWT is pretty standard - my vote is to keep them and make it pluggable at least.

[aeneasr]

Thanks for your input. I think I'll keep it pluggable / optional like you suggested. It's just a few chars and with HTTP/2 I don't think it will be much trouble sending a few more chars.

[tbroyer]

Disclaimer: just came in here from your post on Gopher Academy; I built an OAuth 2.0 Provider –OpenID Connect 1.0 actually– in Java https://github.com/ozwillo/ozwillo-kernel; I'm not a Hydra user.

JWTs as access tokens have only one advantage: they save storage on your server. When you don't support token revocation, then they also save you a hit to your database from the introspection endpoint –or anywhere you need to introspect the token– because they're self-contained.
But:

• they trade storage on your server for network bloat and storage on others' machines
• as soon as you support token revocation (and you claim Hydra does), you'll have to at least make a hit to your DB to check whether the token has been revoked whenever you "introspect" it.
• unless they're encrypted, you're exposing all the "doors" the token can open to anyone bearing it, and this includes anyone of those "doors" receiving it. If you're generating tokens that can be used at several APIs (those APIs calling your introspection endpoint to validate the token and decide whether they should accept it), each one can now know it can also use it at the other ones (through scopes and/or audiences), and possibly gather (private) information about the user. The introspection endpoint can choose to filter the response depending on the client making the request to mitigate those things, but if all the information is embedded in the token this is not possible.

[aeneasr]

Thank's for your feedback. I agree with the points you made. Token revokation is actually built into Hydra which is why I also deem JWT not to be as useful as they might be. On the other hand, client services / apps can easily decode and validate JWTs with Hydra's public key and read important information like subject or issuer. On the other hand, Hydra stores everything in Postgres and does itself not really need JWT to work. I will have to think about this a little bit more.

[aeneasr]

One more point, HTTP/2 multiplexing could render the bloated header argument invalid. This is at least what my gutt is telling me.

[tbroyer]

Clients relying on the token format is fragile (what if Hydra changes to something else as proposed here?) and somehow defeats OAuth2 which states a token is opaque. You're free to do it in a "controlled environment" of course but it's not worth it IMO. You can also return that info in the token endpoint's response for example (à la OpenID Connect's id_token)

Re. HTTP/2, that only holds over the same TCP connection though. If you work with mobiles or otherwise flacky Wi-Fi, it may very well not be true; but also in many other cases I believe. Depends on use-cases though.

[tbroyer]

Ha, looking at osin-storage implementation it looks like you're paying the size cost at all levels. Had you been using your own implementation you could have stored only the revoked jti (along with the token's expiry date to easily clean up the data store) ;-)

[aeneasr]

Thanks @tbroyer , after reading your feedback and sleeping over it, I have to agree that implementing JWT was not the best choice. I will make JWT optional for access tokens or maybe even remove JWT signed access / refresh tokens completely.

[aeneasr]

Thanks all, this is now tracked in #32 .

[aeneasr]

Feel free to post your feedback on #32 (comment)

[vgrabko]

JWT