Qué es OAuth 2.0 y OpenID Connect (OIDC)
Arquitectura de Identidad Digital, Flujos de Tokens con PKCE y Seguridad en APIs
En el desarrollo de software moderno y arquitecturas de microservicios, la gestión de identidad se divide en dos pilares fundamentales: Autenticación (Quién eres) y Autorización (Qué tienes permiso de hacer). Durante años, las aplicaciones solicitaban directamente las contraseñas de los usuarios para interactuar con servicios externos, lo que representaba un riesgo de seguridad inaceptable.
Para resolver esto nacieron los estándares universales de la industria:
En la Tecnología Real (Explicación Sencilla)
authorization_code retornado por el servidor de identidad e intercambiarlo por un access_token sin que nadie lo detecte. - Con PKCE (Proof Key for Code Exchange - RFC 7636): 1. La app genera un secreto aleatorio criptográfico llamado code_verifier. 2. Calcula su hash SHA-256 (code_challenge) y lo envía en la solicitud de autorización inicial. 3. Al recibir el código, la app envía el code_verifier original para reclamar los tokens. 4. El servidor calcula SHA-256(code_verifier) y comprueba que coincida con el code_challenge original. Si un atacante interceptó solo el código, no puede canjearlo porque desconoce el code_verifier original.Comparativa: OAuth 2.0 vs OpenID Connect (OIDC)
| Característica | OAuth 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Propósito Principal | Autorización (delegar permisos de acceso a APIs). | Autenticación (verificar quién es el usuario). |
| Artefacto Principal | Access Token (Bearer Token opaco o JWT). | ID Token (Siempre un JWT firmado criptográficamente). |
| Endpoint Clave | /token, /authorize | /userinfo, /.well-known/openid-configuration |
| Información Contenida | Scopes, expiración, emisor y audiencia. | Claims de identidad (sub, email, name, picture, email_verified). |
| Analogía de la Vida Real | La tarjeta llave de un hotel (te abre la puerta de la habitación). | Tu Pasaporte o Cédula de Identidad oficial (demuestra quién eres). |
Flujo de Intercambio de Tokens con PKCE
# 1. Generación de Verificador y Desafío Criptográfico en el Cliente# code_verifier = "a9b8c7d6e5f4g3h2i1j0k9l8m7n6o5p4q3r2s1t0u9v8w7x6y5z"# code_challenge = BASE64URL(SHA256(code_verifier)) # 2. Solicitud al Endpoint de Autorización (Navegador/App)GET /oauth/v2/authorize? response_type=code &client_id=mi-banca-movil-client &redirect_uri=https%3A%2F%2Fmiapp.com%2Fcallback &scope=openid%20profile%20email%20cuentas%3Aread &state=xyzStateTokenProteccionCSRF123 &code_challenge=E9Melhoa2OwvFrGMTJguCH5... &code_challenge_method=S256 # 3. Intercambio de Código por Tokens (POST Seguro al Token Endpoint)POST /oauth/v2/tokenContent-Type: application/x-www-form-urlencoded grant_type=authorization_code&client_id=mi-banca-movil-client&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fmiapp.com%2Fcallback&code_verifier=a9b8c7d6e5f4g3h2i1j0k9l8m7n6o5p4q3r2s1t0u9v8w7x6y5zNota Técnica
Refresh Tokens o Access Tokens de larga duración en el localStorage del navegador web. El almacenamiento local es vulnerable a ataques de inyección de scripts (XSS). La práctica recomendada por la IETF es utilizar cookies seguras con atributos `HttpOnly`, `Secure` y `SameSite=Strict`.Glosario Técnico de OAuth 2.0 y OIDC
Authorization: Bearer <token> para invocar endpoints protegidos de una API REST.Mini Cuestionario Interactivo3 preguntas
Selecciona una opción para autoevaluarte al instante. La respuesta se califica de inmediato.
¿Cuál es la diferencia fundamental entre OAuth 2.0 y OpenID Connect?
¿Por qué el flujo PKCE (Proof Key for Code Exchange) es obligatorio para aplicaciones Single Page (SPA) y móviles?
¿Qué atributo de cookie protege los tokens de sesión contra ataques de Cross-Site Scripting (XSS)?
Diagnóstico y Práctica en Arostik
Inspecciona, decodifica y valida la estructura de tus tokens de autorización con nuestro Decodificador JWT, genera identificadores seguros con el Generador UUID v4 y audita la seguridad TLS de tu servidor con el Auditor SSL.