El flujo implícito exponía el access token en la URL, y la BCP de seguridad del IETF lo retiró de las recomendaciones en el RFC 9700 (2025). En cliente público, SPA o app móvil, implementas authorization code con PKCE y validas cada claim del ID token antes de confiar en datos de usuario. Este post recorre el flujo y las facturas que cobra producción.

Los roles y lo que cada uno guarda

OAuth separa cuatro roles: el resource owner es el usuario, el client es tu aplicación, el authorization server emite tokens y el resource server protege la API. El cliente público no guarda secret, y por eso existe el PKCE. El redirect URI se registra en el authorization server con comparación exacta; un URI con comodín abre un redirect abierto, y ahí un atacante captura el code en el retorno.

Pruebas el redirect con puerto diferente, con subdominio parecido y con path relativo. La RFC 9700 (IETF, 2025) lista la validación deficiente del redirect URI entre los vectores de interceptación de tokens.

El flujo PKCE paso a paso

Generas un code_verifier aleatorio, calculas el hash SHA-256 y envías el code_challenge junto con la autorización. El authorization server guarda el challenge. En el intercambio del code por tokens, envías el verifier y el servidor compara los dos. El RFC 7636 (IETF, 2015) describe el par. Un atacante que intercepte el code en el dispositivo no posee el verifier y el intercambio falla. El jwt-autenticacao-completa" class="post-internal-link">refresh token rota: el servidor emite un refresh nuevo en cada uso e invalida el anterior; el reuso detectado revoca la familia entera.

ID token no es access token

OIDC se apoya sobre OAuth y agrega el ID token, un JWT firmado por el authorization server. El access token protege la API; el ID token autentica al usuario en el client. Antes de leer nombre, correo o email_verified, validas la firma, iss, aud y nonce contra el discovery document del servidor. OpenID Connect Core 1.0 (OpenID Foundation, 2014) define la separación entre los dos tokens.

Trampas de producción

Un SPA que guarda el access token en localStorage entrega a XSS un camino libre: un script inyectado lee la clave y llama a la API como tú. El patrón BFF (Backend for Frontend) mantiene la sesión en una cookie httpOnly mientras el backend habla OAuth con el authorization server. La sesión termina con logout RP-initiated: el client pide el cierre en el servidor y redirige al usuario de vuelta. Tu suite de seguridad corre cada endpoint con token expirado, token de otro client y token sin scope; los huecos de autorización aparecen en esas tres pruebas.