Estructura y firma del ID Token

In OpenID Connect (OIDC), the ID Token is a crucial piece of information. It's a security token that contains claims about the authentication of an end-user by an Authorization Server.

Think of it as a digital ID card for the user, issued after they successfully log in.

ID Tokens are always formatted as JSON Web Tokens (JWTs). A JWT is a compact, URL-safe means of representing claims to be transferred between two parties.

Every JWT has three main parts, separated by dots:

• Header
• Payload
• Signature

The first part of an ID Token is the Header. It's a JSON object that describes the token itself, like what type of token it is and the algorithm used to sign it.

• alg: The cryptographic algorithm used for signing (e.g., RS256, HS256).
• typ: The type of token, which is usually "JWT".

When you decode the base64url-encoded header, you'll see a JSON object like this. This tells you how the token was secured.

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "someKeyId"
}

The kid (Key ID) helps find the correct public key for verification.

The header is base64url encoded. Here's how you might decode a JWT header string in Java. This helps reveal its content.

The second part is the Payload. This is where the actual "claims" about the user and the authentication event are stored. Claims are statements about an entity (typically the user).

Standard claims you'll often see include:

• iss: Issuer (who issued the token).
• sub: Subject (unique identifier for the user).
• aud: Audience (who the token is for).
• exp: Expiration Time (when the token expires).
• iat: Issued At Time (when the token was issued).

Similar to the header, the payload is also a base64url-encoded JSON object. It contains the identity information you need.

{
  "iss": "https://example.com/auth",
  "sub": "user123",
  "aud": "myAppClientId",
  "exp": 1678886400,
  "iat": 1678882800,
  "name": "Alice Wonderland"
}

exp and iat are Unix timestamps.

The third and final part is the Signature. This is critical for security! It's used to verify that the token hasn't been tampered with and that it comes from a legitimate issuer.

The signature is created by taking the encoded header, the encoded payload, and a secret key or private key, and running them through the cryptographic algorithm specified in the header.

When your application receives an ID Token, it uses the public key (provided by the Issuer) to verify the signature. It re-computes the signature using the header, payload, and the public key.

If the re-computed signature matches the token's signature, you can trust that:

• The token hasn't been altered.
• It was issued by the expected Authorization Server.

Great job! You now understand the fundamental structure of an ID Token.

• Header: Describes the token and signing algorithm.
• Payload: Contains identity claims about the user.
• Signature: Ensures the token's integrity and authenticity.

Each part is base64url encoded and separated by dots, forming a secure and verifiable digital identity for the user.