https://blog.ploetzli.ch/2024/should-i-use-jwt-for-authentication/ [a28ee3469e609] Henryk Plotz * Github * RSS Feed * Mastodon Published 2024-05-26 Skip to content * Imprint/Impressum Henryk Plotz in Essays | 2024-05-26 Should I Use JWTs For Authentication Tokens? No. --------------------------------------------------------------------- Not satisfied? Fine, fine. I'll write a longer answer. Let's talk about what we're talking about. JWT stands for JSON Web Tokens, a reasonably well defined standard for authenticated tokens. Specifically they have a header with format information, a payload, and a signature or message authentication code. The core idea is that whoever has the corresponding verification key can verify that the payload is authentic and has not been altered. What they do with that information is up to them. The JWT spec (RFC 7519) makes suggestions by providing a few well-known registered claim names: issuer, audience, subject, expiration time, etc. A common usage pattern is that, after verifying the authenticity against whatever trust relationship they have with the issuer, the recipient checks whether they are the intended audience (if any is specified) and the expiration time has not yet passed, and then take the subject as an authenticated identity of the bearer of the token. It's perfectly designed for bearer token authentication! Or is it? Let me be clear: JWT as authentication tokens are constructed for Google/Facebook scale environments, and absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs. If you process less than 10k requests per second, you're not Google nor are you Facebook. The core benefit, proponents will tell you, is that the recipient of a JWT doesn't need to connect to the user database to verify the token authenticity and render its service. In a large installation, like Google's, that means that the JWT issuer, the authentication service, can be a dedicated service that is managed and scaled like other services, and is the only service that needs to access the centralized user database. All other services can act on the information stored in the JWT alone, and don't need to go through the user database, which would represent a choke point. What about logout/session invalidation? Well, in order for this model to work, the authentication token should have a fairly short lifetime. Maybe 5 minutes, max. The client is also issued a second token, the so-called refresh token, with which it can request a new authentication token from the authentication service. This gives the authentication service a chance to consult the user database to see whether the user or a specific session has been blocked in the meantime. Here's the twist that is rarely, if ever, spelled out: In this setup the refresh token, not the authentication token, is the real session token. The refresh token represents the session with the authentication service (which can be revoked), while the authentication tokens are just derived credentials to be used for a few requests at most. The beauty, from Google's point of view, is that this delegates keeping the session alive to the client, i.e. not Google's servers. Oh and by the way, the refresh token can be, and usually is, opaque, since it's only ever consumed by the same service that creates it. That reduces a lot of complexity, by just using an opaque identifier stored in a database. Now, let's assume you are not Google. Check which of these apply to you: * You wanted to implement log-out, so now you're keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request. * You need to be able to block users entirely, so you check a "user active" flag in the database. You hit the database on each request. * You need additional relationships between the user object and other objects in the database. You hit the database on each request. * Your service does anything at all with data in the database. You hit the database on each request. Congratulations, if you confirmed any of the items above, you don't need JWTs. You're hitting the database anyway, and I'm pretty sure that you only have one database which stores both your user profiles and your application data. By just using a "normal" opaque session token and storing it in the database, the same way Google does with the refresh token, and dropping all JWT authentication token nonsense, you stand to reap these great benefits: * No weird workarounds (allow/denylist) for shortcomings of JWT as authentication token * Greatly reduced complexity. No need to manage a secure JWT signing/authentication key * You get to pass on some interesting bugs. Just use the normal session mechanism that comes with your web framework and that you were using before someone told you that Google uses JWT. It has stood the test of time and is probably fine. If you need something to do to make you feel like you're running a big deployment, you can probably configure your session mechanism to use [DEL:redis:DEL][INS:valkey:INS] to store the session data. You're still going to use the authenticated user id to query the database, but for unauthenticated requests it may be faster/use less resources. It might not be. You'll have to tune and measure that. [a28ee3469e609] Henryk Plotz Published 2024-05-26 Write a Comment Cancel Reply Write a Comment Comment [ ] [ ] [ ] [ ] [ ] [ ] Name[ ] Email[ ] Website[ ] [ ] Save my name, email, and website in this browser for the next time I comment. [Submit Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. 1. [ident] Bob 2024-05-27 I'm not disagreeing with what you wrote for using JWTs as a session token, but there are other use cases. For example, if you have two applications where each has it's own user and session management, but occasionally you want to send users from one to the other without them having to log in again. One (elegant, imho) solution is that application 1 issues a short lived token and redirects the user agent to application 2, which accepts it as proof that the user has been authenticated. Reply to Bob + [a28ee] Henryk Plotz 2024-05-27 You're right. What you're describing is formalized in OpenID Connect (OIDC) and the JWT for passing user information from an Identity Provider to a Service Provider is then called the ID token, a third token type (besides access and refresh) in the underlying OAUTH2 protocol. The oauth website has a couple of, erm, Opinions on the topic of whether you're supposed/allowed to interpret the access token or derive user information from it: https://oauth.net/2 /access-tokens/ Reply to Henryk 2. [ident] drizzo 2024-05-27 As far as I see it you are mixing authentication, session management and user management. For authentication purposes access/refresh token are quite nice since they are rather hard to forge. For user management, well, you do not want to stuff all the required user claims into that poor token. If you try you will find that there is a limit that nobody specified but is there nonetheless. For session management I agree with you. Token are no good session persistence measures, but they do work. Anyway, there is a reason why developers offload that pesky auth/ user/session stuff to an identity provider, then all those questions above are "someone else's problem" (see Douglas Adam for further instructions). Reply to drizzo 3. [35812] Warren 2024-05-27 I feel like this subject comes up every couple of months with another iteration of why people think JWTs are bad. Claiming JWTs are bad is like claiming that HTTP is bad, data packets are bad, or that currency is bad. For sure some RFCs are bad, this is always true, there are things that are always improving. And it's hard to not point out, that we've even built the successful Auth SaaS-Authress-which does provide JWTs, although we thought long about how session management work work. Reply to Warren 4. [ident] Milian 2024-05-27 I am not one for commenting on other people's articles, but this one just does not make sense to me, and this is why I'll leave my two cents here: In your headline, you say that you *should* not use JWTs -- at the end of the article, you say you do not *need* JWTs. Which one is it? I think that no one ever argued that you absolutely *need* a JWT. The one and only real benefit of a JWT is standardization, and that is exactly why you really *should* use it. Every token format that you implement on your own is -- for a developer that is not yourself -- always going to be inferior to the JWT if you do not document and specify it as well as the RFC does (Which is something most developers will not do). You *should* always strive to use standards the broader community agreed to, instead of reinventing the wheel because you think you know better than others. Nowhere does the RFC for the JWT mention any type of "refresh token" or "session key" and I think you are wildly confusing JWT and OAuth 2.0 in this article and seem to think that these two things are interchangeable. The JWT RFC only specifies the format of the Token itself, and even the RFC for OAuth 2.0 does not *mandate* the use of the JWT format either. Which flow you eventually use a JWT token in is up to you. This is also why the JWT in and of itself will never have anything to do with the amount of database queries you will make, as these will always part of the authentication and authorization protocols and flows. If you rewrote this article to "You most likely do not need OAuth 2.0 in your application" (the emphasis is on *need* instead of *should* because, again, you absolutely should always strive to use standards), then I would probably agree with you, though. Reply to Milian 5. [ident] Henning 2024-05-27 The article is more about Basic Auth vs. JWT, as I read it. And I don't fully get the problem of using one over the other, or what to recommend in a non Google environment, I have to say. One argument always goes, that you're trying to avoid sending your password over the wire all the time with Basic Auth. With JWT this is gonna be less. But is that really important? I couldn't say. I don't know attack vectors that are working with Basic Auth, but not with JWT. Reply to Henning Write a Comment Webmentions Should I Use JWTs For Authentication Tokens? - Tinker, Tamper, Alter, Fry | Scriptease 2024-05-27 [...] Should I Use JWTs For Authentication Tokens? - Tinker, Tamper, Alter, Fry -- Weiterlesen blog.ploetzli.ch/2024/ should-i-use-jwt-for-authentication/ [...] Should I use JWTs for authentication tokens? - CIBERSEGURANCA 2024-05-27 [...] Read More [...] Should I Use jwts For Authentication Tokens? pantalaimon on May 27, 2024 at 10:31 Hacker News: Front Page - Bharat Courses 2024-05-27 [...] Article URL: https://blog.ploetzli.ch/2024/ should-i-use-jwt-for-authentication/ [...] Wo Ying Gai Shi Yong JWTsZuo Wei Shen Fen Yan Zheng Ling Pai Ma ? - Pian Zhi De Ma Nong 2024-05-27 [...] Xiang Qing Can Kao [...] * Related Content by Tag * authentication * JWT * security About me Born between E.T. and Blade Runner, occasionally hacking and breaking things, computer scientist living in Berlin. Archives * May 2024 * May 2022 * August 2020 * June 2020 * November 2019 * October 2019 * May 2018 * March 2018 * July 2016 * November 2015 * September 2015 * April 2015 * December 2014 * November 2014 * October 2014 * August 2014 * May 2014 Categories * Code snippets * Essays * Lessons learned * Rants * Things That Were * Traveling Independent Publisher empowered by WordPress