What are JWTs?
A JSON Web Token (or JWT) is simply a JSON payload containing a particular claim. The key property of JWTs is that in order to confirm if they are valid we only need to look at the token itself.
We don't have to contact a third-party service or keep JWTs in-memory between requests to confirm that the claim they carry is valid - this is because they carry a Message Authentication Code or MAC (more on this later).
A JWT is made of 3 parts: the Header, the Payload and the Signature. Let's go through each one, starting with the Payload.
JWT signatures - How are they used for Authentication?
The last part of a JWT is the signature, which is a Message Authentication Code (or MAC). The signature of a JWT can only be produced by someone in possession of both the payload (plus the header) and a given secret key.
Here is how the signature is used to ensure Authentication:
the user submits the username and password to an Authentication server, which might be our Application server, but it's typically a separate server
the Authentication server validates the username and password combination and creates a JWT token with a payload containing the user technical identifier and an expiration timestamp
the Authentication server then takes a secret key, and uses it to sign the Header plus Payload and sends it back to the user browser (we will cover later the exact details on how the signature works )
the browser takes the signed JWT and starts sending it with each HTTP request to our Application server
The signed JWT acts effectively as a temporary user credential, that replaces the permanent credential wich is the username and password combination
And from there, here is what our Application server does with the JWT token:
our Application server checks the JWT signature and confirms that indeed someone in possession of the secret key signed this particular Payload
The Payload identifies a particular user via a technical identifier
Only the Authentication server is in possession of the private key, and the Authentication server only gives out tokens to users that submit the correct password
therefore our Application server can safely be sure that this token was indeed given to this particular user by the Authentication server, meaning that it's indeed the user as it
had the right password
The server proceeds with processing the HTTP request assuming that it indeed it belongs to that user
The only way for an attacker to impersonate a user would be to either steal both its username and personal login password, or steal the secret signing key from the Authentication server.
As we can see, the signature is really the key part of the JWT!
The signature is what enables a fully stateless server to be sure that a given HTTP request belongs to a given user, just by looking at a JWT token present in the request itself, and without forcing the password to be sent each time with the request.
Top comments (0)