JWT confusing. How does the application server authenticate?

2
votes

This article on JWT is super clear except for the last part.

Parts I understand: 1. Encoding is diff from encryption. 2. The token's parts (header base64 encoded, payload base64 encoded, signature which header+payload encrypted with the public key and a specified algo)

But I don't understand how the token verification is handled in part 5. I also don't understand why the header and the payload need to be Base64 encoded. Given that it's not secure or encrypted... what's the part of the encoding?

*****EDIT****

Am I right in understanding that since the JWT contains an encoded header and payload... the application server can just use its secret key (perhaps a public key in an asymmetric encryption mechanism) to encrypt the included payload and header and if it arrives at the same included JWT signature... then the application server knows that the data hasn't been tampered with and the user did indeed authenticate with the authentication server. Is this right?

If the signatures don't match. What does this imply?

1
jwt
You got it. If signatures don’t match, application should not create any session. Apart from signature, application should also verify the expiration time of JWT. There are many libraries in every platform which can do this for you. Check this page: jwt.io – Agam

1 Answers

6
votes

JWT uses base64Url encoding (see https://www.rfc-editor.org/rfc/rfc7519#section-3), which avoids the characters +, / and = which are reserved characters for URIs (see section 2.2. in https://www.ietf.org/rfc/rfc2396.txt)
This makes sense because in some cases the token is transferred as a parameter in the url.

If asymmetric algorithms are used, the hashing is done with the private key, thus making it impossible for anyone who knows the public key to create a new signature.

Step 5 in the tutorial just tells you, that the application server will create a hash from header and payload, using the same key as the authentication server, and compares if it gets the same value as in the JWT it received in the request. The implication of a non-matching signature is that someone changed the token and therefore the token is considered invalid and authorization will be denied. Technically it's quite easy to manipulate the header and payload of a JWT, just decode the base64url encoded parts, change some values in the JSON structure, eg. the expiry time exp, and encode it again. But without knowing the private key you can't create a valid signature for it.

Check out https://jwt.o and play with the example token in the debug window to see the effect.