Keeping applications secure by evolving OAuth 2.0 and OpenID Connect#

Alexander Schwartz (Keycloak maintainer)

• Why: OAuth 2.0/OIDC are being actively hardened — FAPI 2.0 (2025), RFC 9700 Best Current Practice, and the OAuth 2.1 draft — and this maps exactly what changes for real applications, with Keycloak as the enforcement vehicle.
• What: A standards-evolution walkthrough anchored in the FAPI 2.0 attacker models (what's assumed safe — TLS, JWKS, browsers, sessions — vs. what attackers can do), followed by the concrete practice set: PAR (pushed authorization requests) to keep flow parameters out of URLs, PKCE S256, private-key JWT (no public clients), no wildcard redirect URIs, and sender-constrained tokens.
• How: Deep, current treatment of DPoP (demonstrating proof-of-possession): ephemeral client key pairs bind access and refresh tokens so stolen tokens are unusable — including the HTTP method/URI/proof/nonce alignment that makes or breaks a DPoP request — and mTLS-bound tokens with their operational constraints. Keycloak implements all of this via client profiles/policies validated on client update, login, and token issuance (FAPI 2.0 and OAuth 2.1 draft both supported). Migration tactics are practical: enforce one practice at a time, then "brownouts" (temporary enforcement windows) to force cleanup before permanent cutoffs.
• Where applicable: Any IAM rollout — the migration playbook is vendor-neutral even where the demos are Keycloak. Especially relevant if you operate public clients or SPAs, where DPoP changes the threat model for token theft.