OAuth 2.0 y OpenID Connect, paso a paso

Vas a hacer un inicio de sesión real contra un servidor de autorización de laboratorio. En cada paso verás la petición exacta, lo que responde el servidor y por qué. Y podrás romperlo a propósito para ver cómo se defiende.

Túel usuario

Lab SPAla aplicación (este navegador)

Servidor de autorización/as/* en este mismo dominio

1
La aplicación prepara la petición

Antes de mandarte a iniciar sesión, la aplicación genera tres valores aleatorios y los guarda: state (contra CSRF), nonce (contra reutilizar un id_token) y el code_verifier de PKCE. Al servidor solo le envía el hash del verifier: el code_challenge.

Petición de autorización
Rómpelo El atacante cambia el state de vuelta (CSRF) Usar una redirect_uri no registrada
2
Vuelves con un código

El servidor te redirige de vuelta con un code de un solo uso y el mismo state. La aplicación comprueba que el state es el que guardó: si no coincide, la respuesta no la ha iniciado ella y la descarta.
3
Canjear el código por tokens

La aplicación envía el código junto con el code_verifier original. El servidor calcula su SHA-256 y lo compara con el code_challenge del paso 1. Así, aunque alguien robara el código, no podría canjearlo.

Petición
Rómpelo Enviar un code_verifier distinto (como haría un atacante con un código robado)

Respuesta
```
—
```
4
Inspeccionar y validar los tokens

Un JWT son tres partes en base64url: cabecera, datos y firma. Cualquiera puede leerlo; solo el servidor puede firmarlo. La aplicación valida el id_token con la clave pública del servidor (JWKS).
Cabecera
Datos (claims)
Validación
Rómpelo
5
Usar el access_token

El access_token es la llave para llamar a APIs. El id_token solo sirve para que la aplicación sepa quién eres: no debe usarse para llamar a una API, y este servidor lo rechaza.
```
—
```

Lo que este laboratorio simplifica

Los usuarios son de prueba y no se pide contraseña: el foco está en el protocolo, no en la autenticación. El segundo factor (MFA) se simula con una casilla.
El código de autorización es un JWT firmado y sin estado, válido 60 segundos. Un servidor real lo guarda y lo invalida al primer uso, para impedir que se canjee dos veces.
Los tokens se guardan en sessionStorage para poder mostrarlos. En una aplicación real se evita exponerlos así (por ejemplo, con un backend-for-frontend).

Configuración pública del servidor: /.well-known/openid-configuration · /as/jwks

OAuth 2.0 y OpenID Connect, paso a paso

La aplicación prepara la petición

Vuelves con un código

Canjear el código por tokens

Inspeccionar y validar los tokens

Usar el access_token

Lo que este laboratorio simplifica