26

Currently I'm learning about JWT and started with the token based authentication. I don't understand the sentence from the article:

Token based authentication works by ensuring that each request to a server is accompanied by a signed token which the server verifies for authenticity and only then responds to the request.

What is signed token? What does it mean to sign a token? I can't find the question on SO.

Artem Malchenko
  • 2,320
  • 1
  • 18
  • 39

1 Answers1

27

A signature is something that can be verified.

The main problem you're trying to solve is this: the server creates some arbitrary value, the token, which it gives to the client. The client subsequently gives it back to the server as proof of something (proof that they're authenticated, for instance). Now, how can the server be sure that the token is genuine, and the client didn't just make it up?

That's where the signature comes in. It's part of the token, and the server can verify that it had previously created that signature, and that the signature was created for this particular token. In a nutshell, the signature is a hash of the contents of the token plus a secret only the server possesses; to verify the signature the server repeats the hash of the token's contents and the secret only it has, and if it matches, that means the token's signature must have been created the same way which assures the two desired attributes of authenticity.

For the gnarly details of how a JWT signature is computed specifically, read the specification.

Community
  • 1
  • 1
deceze
  • 510,633
  • 85
  • 743
  • 889
  • 1
    Why a signature is **content** + secret? Why it isn't only secret? – Artem Malchenko Jan 30 '18 at 09:11
  • 5
    Because this ties the signature to the specific content. If it was just the secret, every signature would be identical and you could reuse signatures for different tokens. – deceze Jan 30 '18 at 09:35
  • This sounds like it involves some level of cryptography. For the context of an API, is it not secure to issue a random UUID as an access token and verify it by looking in a database who that UUID was issued to? – Tyler Sep 17 '18 at 23:55
  • 1
    @Tyler Yes, but… that requires the server to keep information associated with that token server-side. It requires the server to be stateful. JWT in particular allows the server to be stateless, since the signed JWT token contains all the information within itself. That allows for easier scaling of the server implementation, since you don't need a central token/information store. – deceze Sep 18 '18 at 07:09
  • @deceze but if you don't keep a central token store you cannot revoke a token. Is token signing plus central token store worth it? – Ortomala Lokni Feb 27 '19 at 08:25
  • 1
    @Ortomala You cannot revoke *individual* tokens easily, true. But there are of course ways to deal with that. Often you use JWTs when you need *temporary* tokens which expire by themselves after a reasonably short time anyway. Alternatively you could rotate your server keys, expiring *all* tokens (obviously the nuclear option). Or you keep a blacklist of revoked tokens which you can propagate somewhat slowly across machines, instead of needing to replicate a whitelist of valid tokens which needs to be up to date on all machines at all times. – deceze Feb 27 '19 at 08:35