[HN Gopher] Anatomy of a JWT
___________________________________________________________________
Anatomy of a JWT
Author : mooreds
Score : 65 points
Date : 2022-02-28 13:35 UTC (1 days ago)
(HTM) web link (fusionauth.io)
(TXT) w3m dump (fusionauth.io)
| whoknew1122 wrote:
| Really nice write-up.
| halestock wrote:
| https://jwt.io/ is also a great resource for analyzing JWTs
| interactively (with the usual caveats about pasting sensitive
| information into a random text box).
| senko wrote:
| Don't use JWT: https://fly.io/blog/api-tokens-a-tedious-survey/
| (by @tptacek)
| ivanhoe wrote:
| IMHO rule of the thumb is: If you can get away with simple
| random tokens, use that. If you can't (high-traffic distributed
| apps, microservices, serverless, etc.) JWT is probably the next
| easiest solution.
| senko wrote:
| That's reasonable.
|
| I see so many cases where someone asks "what should I use for
| auth" and immediately the answer given is JWT, where simple
| random tokens or session auth would be just fine. And simpler
| to implement, since they're supported out-of-the box in many
| frameworks.
| robotdan wrote:
| This is a good point. Keeping it simple is always a good
| engineering choice.
|
| I think one of the reasons JWTs come up so often is that if
| you are going to use OAuth2/OpenID Connect - ideally the
| Authorization Code grant, then tokens become an important
| component.
|
| And many IdPs implement the OAuth2 access token as a JWT.
| So it may be that your IdP ends up making this choice for
| you. Then you have to learn how to deal with JWTs.
| rahulpadalkar wrote:
| Why use JWT? https://www.educative.io/edpresso/why-should-you-
| use-jwts
|
| There are downsides for almost everything out there. Outright
| dismissing JWTs is not correct.
| phendrenad2 wrote:
| Agreed, JWTs fill a niche, and there are also several footguns,
| and most people are better off avoiding them.
| mooreds wrote:
| I respectfully disagree. (Full disclosure: I'm the author of
| the post and work at a company with software that produces a
| lot of JWTs.)
|
| Like any tool, JWT can be misused and you can do insecure
| things with it. I actually quote @tptacek in a different
| article about JWTs: https://fusionauth.io/learn/expert-
| advice/tokens/building-a-...
|
| However, JWTs have strengths too. They are: *
| flexible * widely supported * standardized
| * stateless * portable * relatively easy to
| understand * extendable
|
| They also have libraries (often open source) to help you
| generate and consume them in almost every programming language,
| which is a huge help when it comes to using a tool securely.
|
| Edit: fixed typo (relative -> relatively).
| merlincorey wrote:
| Why not PASETO?
| mooreds wrote:
| Widespread support is the biggest obstacle to PASETO
| adoption. Classic chicken and egg problem. I am also not
| aware of it being standardized (a brief google shows it is
| in progress, which is nice).
|
| Other than that, it seems nice. A better JWT than JWT with
| some of the sharp edges removed.
|
| I've actually filed an issue for our product to support
| PASETO and it's gotten some community support, but not an
| overwhelming amount.
| [deleted]
| Sohcahtoa82 wrote:
| > stateless
|
| This is a bug, not a feature, especially if you make your
| tokens long-lived. If your implementation is completely
| stateless, then there's no way to invalidate a token to allow
| a user to log out. If a JWT somehow gets stolen, the user has
| no way to terminate the stolen session.
|
| At best, you could create a blacklist of tokens that have
| been invalidated, which would delete rows as time goes on and
| the tokens reach their natural expiration date to avoid the
| database growing forever. But at that point, it's no longer
| stateless.
| mooreds wrote:
| > especially if you make your tokens long-lived
|
| Agreed! You should never make tokens long lived. Seconds to
| minutes is what we typically see.
|
| "But won't users have to log in whenever the token
| expires?" Nope, that's what the refresh grant (in the OAuth
| world) is for. I am not as familiar with other uses of JWT,
| but I suspect there is a similar process that relies on the
| issuer for them.
|
| > But at that point, it's no longer stateless.
|
| Agreed, it is an architectural choice. You can choose the
| benefits of statelessness (scale) at a cost of revocation
| difficulties. You can get revocation, but you have to re-
| introduce state.
|
| Is there some token solution out that that I'm unaware of
| that gives you statelessness and revocation? Would love to
| learn more about it if so.
| spyspy wrote:
| JWTs can totally store state. I've found good use cases for
| it and I've never understood why people immediately get up
| in arms about it - possibly conflating the concepts of JWTs
| themselves and OAuth 2.0. It's just a damned signed json
| blob. Trying to act like it's anything more is missing the
| point.
| emaginniss wrote:
| The statelessness being discussed here is about server-
| side statelessness. It allows you to build a server that
| gets all the needed information about a transaction from
| the data being provided (url, body, headers) rather than
| having to look up authentication information based on a
| token that the request carries. This is valuable when you
| want to keep your servers very scalable without relying
| on a shared data storage mechanism that they must all
| keep up to date with authentication tokens and data.
| LVB wrote:
| I do wonder what percentage of folks are actually in a position
| to choose? For a lot of people they're going to be interacting
| with JWTs because they're dealing with someone else's auth, so
| the more they know about this structure the better.
| mooreds wrote:
| That's a great point. As a dev, lots of times you're working
| with an auth provider, either from a social login like Google
| or from a centrally managed service.
|
| In either case, you can suggest "let's use <X> token" where X
| is paseto or something else, but you can't dictate it (Google
| certainly won't listen and change formats :) ).
| rad_gruchalski wrote:
| Why not? The article does not really answer why not.
|
| > This is a problem because the ability to read your user
| profile isn't a good identity proof. You might grant that
| capability to applications for reasons having nothing to do
| with whether they can "log in with Twitter" to a dating app.
| People found a bunch of vulnerabilities.
|
| > Enter OpenID Connect (OIDC). OIDC is the demon marriage of
| OAuth 2.0 and a cryptographic token standard called JWT. OIDC's
| is unambiguous: it gives you an "Identity Token", JWT-encoded,
| that tells you who's logging in.
|
| Ah, so it's more of a case "don't use jwt... incorrectly".
|
| I also recommended looking at UMA2 and resource servers.
| Keycloak has, what I'd call, my to go reference implementation.
| navbaker wrote:
| This is a great, easy to understand breakdown, thanks a bunch!
| I'm at the tail end of having to transition an existing, not well
| documented codebase from Identity Server to Keycloak and had zero
| experience with auth prior to starting. I found the jargon to be
| the toughest part, as well as learning the hard way all the
| little things that more experienced devs take for granted like
| the subtle differences in how the backend API is granted auth vs.
| how the front-end clients are granted auth.
| vsareto wrote:
| Modern claims auth just sucks to learn. You're not alone.
| [deleted]
___________________________________________________________________
(page generated 2022-03-01 23:01 UTC)