hello , in this part we will find how to read the JWT.
In the first two parts of this series, we:
- Established a secure Service-to-Service (S2S) flow using Keycloak’s Client Credentials Grant.
- Proved our token contained the necessary Audience (aud) claim using Postman.
Now, let’s address the fundamental question: What exactly is that huge, cryptic string we call the Access Token? It looks like a random, daunting string, but it’s actually a compact, self-contained digital passport—the JSON Web Token (JWT).
When we successfully used Postman to get a token from Keycloak, we received a JWT. Understanding its structure is key to debugging and trusting your security layer.
What is a JWT? (The Digital Passport)
A JSON Web Token (JWT), pronounced “jot” is an open standard (RFC 7519) for securely transmitting information between two parties. Instead of a microservice needing to query a central user database on every request, the JWT itself contains all the necessary authorization information, making the system stateless and highly scalable.
The Three Parts of the Token
A JWT is always composed of three distinct parts, separated by periods (.), each of which is Base64URL-encoded:
1. Header (The Metadata)
The first section contains metadata about the token itself, typically specifying:
- typ: The token type, which is usually JWT.
- alg: The signing algorithm used to create the signature, such as RS256. This tells the receiving service how to cryptographically verify the token.
2. Payload (The Claims)
This is the core of the JWT. The Payload contains the “Claims,” which are statements about the token holder (our chat-app-service client) and additional data. For our S2S flow, the most important claims are:
- iss (Issuer): Who issued the Token (in our case, Keycloak).
- sub (Subject): The user or client identifier.
- exp (Expiration): When the Token will expire. This enforces short-lived credentials.
- aud (Audience): Crucially, this is the Client ID of the intended recipient (our crm-api-gateway), ensuring the token can’t be reused elsewhere.
3. Signature (The Integrity Seal)
The Signature is the cryptographic seal that ensures the token has not been tampered with and is trustworthy.
The Signature is created by:
- Taking the encoded Header and the encoded Payload.
- Running them through the signing algorithm (e.g., RS256).
- Using Keycloak’s Private Key (which must be kept secret) to generate the final hash.
When our CRM API Gateway receives the token, it uses Keycloak’s publicly available Public Key to recalculate the signature. If the calculated signature matches the Signature in the token, the token is deemed valid and trusted.
The Developer’s Secret Weapon: Decoding the String
That “daunting looking huge string” is just two Base64URL-encoded JSON objects (Header and Payload) that are easy to inspect.
As we did in the Postman verification step, the simplest way to “decode” the token (meaning, view the Header and Payload) is to use an online tool:
- Copy the entire Access Token string from Postman.
- Paste it into the JWT Debugger – jwt.io.
The debugger will instantly parse the three sections, converting the encoded Header and Payload back into readable JSON. This is how we confirm that Keycloak correctly inserted our crm-api-gateway ID into the aud claim and that the token is set to expire as intended.
By using this approach, we turn a complex security component into a simple, self-verifying component that works seamlessly across our microservices architecture. The days of fragile AD service users are officially over!
AVI E.