The Keycloak-Token-Configuration Mistake, 90% of All Developers Do (and How To Avoid It)
summary
Keycloak by default stuffs access tokens with profile claims, realm and client roles and many audiences, causing oversized tokens and GDPR risk; demos use the admin UI Evaluate, client-scope mappers (remove personal claims from access token) and the add to ID token/add to access token toggles to strip email/profile, show real-world counts (2,000–3,000 roles, users with ~1,500 mappings), and switch off full scope allowed to include only specific client roles. Token exchange with an audience parameter issues a proper-targeted token; access tokens can’t be revoked so keep them short and validate the audience.
AI-written summary · about
chapters (8)
- 0:00Keycloak token config mistakes
- 2:26Default token overloading
- 5:13GDPR and token data
- 9:28Removing roles from tokens
- 13:19Audience claim and scope
- 16:28Token exchange for APIs
- 22:16Security risks of defaults
- 23:38Q&A
related talks
04mProject Lightning Talk: How to get your custom access tokens from Keycloak
26mKeycloak Introduction and Demo
48mAdding business logic to your tokens. What could possibly go wrong
33mYour Identity Is Mine: Techniques & Insights From OS Identity Providers Research
31mDelegate Authentication and a Lot More To Keycloak With OpenID...
33mBreaking Tokens: Modern Attacks on OAuth, OIDC, and JWT Auth Flows
16mNo More Configuration Confusion! Keycloak Mapper Basics for SEs – How to Work with...
01h 05mCommon mistakes and misconceptions in Web App Security using OAuth 2.0 and OpenId Connect