Skip to content
MB
2 min readDraft

Token design in modern IAM systems: claims, enrichment, and minimization

A technical draft on token structure, claim minimization, enrichment logic, API gateway constraints, and validation responsibilities.

OAuth2OIDCToken DesignAPI Security
Back to blog

Tokens Are Interfaces

In IAM architecture, tokens are often treated as implementation details. In practice, they are interfaces between the Identity Provider, applications, APIs, gateways, monitoring systems, and sometimes business processes.

Bad token design creates coupling, data exposure, authorization confusion, and operational fragility. Good token design is lean, understandable, validated consistently, and documented for developers.

Minimize Before Enriching

Token enrichment can be useful, but it should not become a dumping ground for identity data. Every claim should have a reason to exist.

Useful questions:

  • who consumes the claim;
  • whether the claim is stable enough for authorization;
  • whether the value belongs in the token or should be fetched from an API;
  • whether the claim exposes sensitive information;
  • how the claim is logged, monitored, and retained.

Access Tokens and ID Tokens

ID tokens are for the client. Access tokens are for protected resources. Confusing the two leads to fragile integrations and weak authorization boundaries.

Developer documentation should make the distinction explicit:

  • intended audience;
  • validation requirements;
  • token lifetime;
  • required claims;
  • optional claims;
  • refresh behavior;
  • logout and session constraints.

API Gateway and Validation Responsibilities

When an API gateway is involved, validation responsibilities need to be defined clearly. A gateway may validate signature, issuer, audience, expiry, mTLS constraints, and selected policy rules. Backend services may still need to enforce business authorization.

The common failure is assuming validation equals authorization. It does not. Validation proves the token is structurally and cryptographically acceptable. Authorization decides whether the caller can perform the action.

Logging and Monitoring

Tokens should not be logged raw. Monitoring requirements should define which fields can be safely captured, how correlation is handled, and what events matter for SIEM integration.

Useful events include failed validation, audience mismatch, issuer mismatch, expired token, suspicious token reuse, and abnormal authorization failures.

Key Takeaways

  • Tokens are contracts, not random containers.
  • Claim minimization reduces exposure and coupling.
  • Gateway validation and application authorization must be documented separately.