01
Un flujo para el portal ficticio
OAuth 2.0 organiza la delegación de acceso. OpenID Connect añade una capa de autenticación. Para el portal se propone Authorization Code con PKCE: el cliente relaciona la solicitud con un secreto efímero y demuestra su posesión al canjear el código. Registra exactamente las URI de retorno admitidas.
En esta ruta se evita el flujo implícito y el intercambio de la contraseña de la persona por parte del cliente. El portal inicia la operación, recibe un código y completa el intercambio con el servicio de identidad. Vincula la respuesta al intento iniciado para prevenir respuestas inyectadas o asociadas a otra sesión.
02
El contrato de cada token
El ID token informa al cliente sobre la autenticación; no debe utilizarse como credencial de acceso a la API. El access token está dirigido al recurso autorizado. El refresh token permite renovar acceso y exige protección propia. No todos los access tokens son JWT: un token opaco requiere el mecanismo de validación acordado.
Para un JWT de acceso, fija emisor, audiencia, algoritmos permitidos, claves confiables, expiración y demás condiciones del perfil. Verifica firma y tiempos antes de usar sus claims. No aceptes una URL de claves elegida libremente por el token. La rotación de claves debe tener una política controlada y verificable.
03
La sesión del navegador
En el diseño del ejercicio, los tokens permanecen en el servidor del portal y el navegador conserva un identificador de sesión mediante una cookie Secure, HttpOnly y SameSite apropiada al flujo. Esa elección requiere protección CSRF; no elimina el riesgo de código malicioso en la página.
Define expiración por inactividad y absoluta, renovación del identificador ante cambios de privilegios y cierre efectivo en servidor. Eliminar una cookie no revoca automáticamente un token autocontenido que otro actor haya copiado. Decide entre revocación consultable, vida corta y controles adicionales para limitar esa ventana.
04
Casos que el contrato debe rechazar
Prueba un token expirado, uno válido para otro destinatario, otro emitido por un origen no confiable y un ID token enviado a la API. Todos deben fallar antes de consultar reservas. Una renovación también debe respetar el estado actual de la persona y los permisos del cliente.
En la plantilla, escribe datos simbólicos como emisor-identidad y api-reservas. No necesitas credenciales reales. Explica el manejo de errores y qué identidad o correlación se registra sin almacenar el token. Para clientes públicos, protege la renovación con rotación o tokens vinculados criptográficamente al cliente según el diseño adoptado.
Criterios para aplicarlo
- El portal valida su respuesta de autenticación; la API exige un access token dirigido a api-reservas.
- Verificar firma, emisor, audiencia y tiempos con una configuración confiable.
- Conservar tokens del lado servidor en el diseño elegido; proteger la cookie y las operaciones frente a CSRF.
05 · Práctica guiada · opcional
Practica lo aprendido
Describe el flujo y decide qué acepta cada componente.
- 01Dibuja solicitud, código, canje y sesión del portal.
- 02Separa destinatario y propósito de los tres tipos de token.
- 03Define validaciones y gestión de claves de confianza.
- 04Documenta expiración, revocación, CSRF y pruebas negativas.
Ver solución orientativa
El portal valida su respuesta de autenticación; la API exige un access token dirigido a api-reservas.
Verificar firma, emisor, audiencia y tiempos con una configuración confiable.
Conservar tokens del lado servidor en el diseño elegido; proteger la cookie y las operaciones frente a CSRF.
Rechazar expiración, audiencia incorrecta y sustitución por ID token; documentar la ventana residual tras una baja.
06
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿PKCE sustituye la autorización por reserva?
No. Protege el canje del código; la API sigue evaluando permisos sobre cada recurso.
02¿Un JWT está cifrado por estar firmado?
No. La firma protege autenticidad e integridad; no garantiza confidencialidad del contenido.
Cómo demostrar el objetivo
Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.
- El flujo distingue código, ID token, access token y refresh token.
- La matriz rechaza emisor, audiencia o tiempos incorrectos y un ID token usado para acceder a la API.
Qué debes recordar
- OAuth delega acceso; OpenID Connect aporta autenticación.
- Decodificar un token no demuestra su autenticidad.
- Cerrar una sesión y revocar un token son decisiones relacionadas, pero distintas.
Tu cuaderno · notas personales
Cuaderno local
Tus notas del contenido
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Material de apoyo · descarga, glosario y referencias
Consulta las condiciones de reutilización de los recursos descargables. Procedencia y condiciones de uso.