Token Hygiene – Why Your Keycloak Access Tokens Need a Diet
Main Room - Castle Hall
Keycloak's default token configuration is
generous: roles, claims, metadata – everything
lands in the Access Token right away. That's
convenient and gets you started fast. But over
time, tokens grow silently. They carry
information that recipients don't need,
shouldn't see, or that simply doesn't belong
there. What starts as a comfort feature
becomes a liability – bloated HTTP headers,
tokens that leak internal structure to third
parties, and a configuration that's hard to
reconcile with GDPR's data minimization
principle.
Token hygiene means treating token contents
as a conscious design decision, not as a default
you never revisit. In this session, I'll walk
through Keycloak's client scope and mapper
configuration to show which claims actually
belong in which token – and which don't. We'll
look at practical strategies for keeping Access
Tokens lean, including Token Exchange as a tool
to issue purpose-built, audience-specific tokens
for downstream services instead of forwarding
one overloaded token everywhere.
You'll leave with a clear understanding of how
to configure Keycloak for minimal, GDPR-friendly tokens – where each recipient gets
exactly what it needs, and nothing more.