With that history and some standards as a foundation, how can we process the JWT from above and what information does it hold?
The JWT above consists of three parts, separated each by a dot (‘.’):
- Header:: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
- Payload: eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
- Signature: _iVbBcypdse-9sjrxp9iOrGsXKBWrBB3mrHgBtukcfM
Both the header and payload are base64url encoded and, not taking possible padding into account, can be decoded like this:
henrik@home> base64 -d <<< eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{"alg":"HS256","typ":"JWT"}
henrik@home> base64 -d <<< eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
{"sub":"1234567890ABC","name":"Henrik Loeser","iat":1611140400,"exp":1611234567}base64: invalid input
The header contains information about the utilized alg(orithm) — here, HS256 (HMAC SHA256).The payload depends on the kind of (access/refresh/ID/…) token and is made up of claims. Those and other predefined JOSE header and payload fields are managed by IANA. In the example above, the fields and claims are subj(ect), name, issued at (iat) and exp(iration time).
The signature is computed by applying the stated algorithm to the concatenation of header, ‘.’ and payload and then base64url encoding the result. Thereafter, the three parts separated by a dot make up the JWT. Details of how signature are derived are defined in RFC 7515.
You can access the above JWT in this online debugger at JTW.io. First, it will show a message “Invalid Signature.” You can resolve it by replacing the shown default secret with !!!my-really-big-256-bit-secret!!!.