Protocolos OAuth 2.0 y OpenID Connect
💡 El Tip Rápido
Clave: OAuth es para autorización (permisos), OpenID es para autenticación (identidad).
La Necesidad de la Identidad Federada
En el Internet moderno, los usuarios no quieren crear una cuenta nueva para cada sitio web. Los protocolos OAuth 2.0 y OpenID Connect (OIDC) permiten que un usuario se identifique usando un proveedor de confianza (como Google o GitHub) sin entregar su contraseña al sitio web de destino. Esto mejora la seguridad y la experiencia de usuario.
OAuth 2.0: El Marco de Autorización
OAuth 2.0 no es un protocolo de autenticación, sino un marco de autorización. Permite que una aplicación obtenga acceso limitado a los recursos de un usuario en otro servicio. Su funcionamiento se basa en la emisión de Access Tokens.
- Resource Owner: El usuario.
- Client: La web que pide el acceso.
- Authorization Server: El proveedor (ej. Google). Cuando ves el mensaje "¿Deseas permitir que esta app acceda a tus contactos?", estás participando en un flujo de OAuth.
OpenID Connect (OIDC): La Capa de Identidad
Como OAuth solo gestionaba permisos, se creó OIDC como una capa sobre OAuth 2.0 para gestionar la autenticación. OIDC introduce el ID Token, un objeto estructurado que contiene información sobre el usuario (nombre, email, foto). Este token suele enviarse en formato JWT (JSON Web Token).
Anatomía de un JWT
Un JWT consta de tres partes: Header, Payload (datos del usuario) y Signature. La firma es la parte técnica más crítica, ya que permite al sitio web receptor verificar que el token fue realmente emitido por Google y que no ha sido alterado en el camino, sin necesidad de consultar al proveedor en cada petición.
📊 Ejemplo Práctico
Escenario Real: Implementación de 'Login con Google' en una App
Quieres que tus usuarios entren en tu plataforma usando su cuenta de Google.
Paso 1: Registro en el Developer Console. Obtienes un Client ID y un Client Secret. Configuras la Redirect URI, que es la dirección de tu web a la que Google enviará al usuario tras loguearse.
Paso 2: El redireccionamiento. Envías al usuario a la URL de Google con los 'scopes' necesarios (openid, email). Google le pide al usuario que confirme su identidad.
Paso 3: Intercambio del Código. Tras el OK, Google devuelve al usuario a tu web con un 'Authorization Code'. Tu servidor (por detrás) envía ese código junto con tu Client Secret a Google para canjearlo por tokens.
Paso 4: Validación del ID Token. Recibes el ID Token (JWT). Tu código debe verificar la firma usando la clave pública de Google. Una vez validada, extraes el email del usuario y creas su sesión en tu sistema. Nunca has visto su contraseña, lo que reduce tu responsabilidad legal y técnica.