OAuth 2.0 y OpenID Connect
Comprender OAuth 2.0 y OpenID Connect es fundamental para integrar Auris correctamente. Esta página explica los protocolos, sus diferencias, los tipos de concesión admitidos por Auris y cómo Auris los implementa internamente.
¿Qué es OAuth 2.0?
OAuth 2.0 (RFC 6749) es un framework de autorización. Proporciona una forma estándar para que un usuario otorgue a una aplicación de terceros acceso limitado a sus recursos en otro servicio, sin exponer sus credenciales a dicha aplicación.
La idea clave es que OAuth 2.0 se trata de delegar el acceso — no de verificar la identidad. Cuando inicias sesión en una aplicación de terceros usando “Iniciar sesión con Google”, Google utiliza OAuth 2.0 para conceder a la aplicación acceso a los datos de tu perfil, no para demostrar que eres quien dices ser. Eso es una capa separada.
Roles principales en OAuth 2.0
| Rol | Descripción |
|---|---|
| Resource Owner | El usuario que posee los datos y concede el acceso |
| Client | La aplicación que desea acceder a los datos |
| Authorization Server | El servidor que emite los tokens (Auris) |
| Resource Server | La API que protege los datos |
En Auris, el Authorization Server y el Resource Server forman parte de la misma plataforma. El Client es tu aplicación y el Resource Owner es tu usuario.
Lo que OAuth 2.0 no hace
OAuth 2.0 no:
- Define cómo un usuario demuestra su identidad (sin protocolo de inicio de sesión)
- Especifica qué información contiene un access token
- Define cómo los resource servers validan los tokens
Estas carencias llevaron a la creación de OpenID Connect.
¿Qué es OpenID Connect?
OpenID Connect (OIDC) es una capa de autenticación construida sobre OAuth 2.0. Responde a la pregunta que OAuth 2.0 deja sin responder: “¿Quién es este usuario?”
OIDC extiende el flujo Authorization Code de OAuth 2.0 introduciendo:
- El ID Token — un JWT firmado con la identidad del usuario (ID de usuario, email, nombre, etc.)
- El Endpoint UserInfo — donde el cliente puede recuperar claims adicionales del usuario
- Claims estandarizados — un conjunto definido de nombres de claims (
sub,email,name,picture, etc.) - Discovery Document — una URL conocida que describe los endpoints del proveedor
Cuando usas OIDC, solicitas el scope openid además de cualquier otro scope. La presencia de openid en el scope indica al servidor de autorización que emita un ID Token junto al access token.
La diferencia en la práctica
| OAuth 2.0 | OpenID Connect | |
|---|---|---|
| Propósito | Autorización (delegación de acceso) | Autenticación (verificación de identidad) |
| Token emitido | Access token (opaco o JWT) | Access token + ID token |
| Info del usuario en el token | No estandarizada | Estandarizada (sub, email, name, etc.) |
| Quién es el usuario | Desconocido | Establecido por el ID token |
| Caso de uso | ”¿Puede esta app leer mi calendario?" | "¿Quién es este usuario?” |
En Auris, todo flujo de login alojado es OIDC — el scope openid se incluye por defecto y la respuesta de tokens siempre contiene un ID token además de los tokens de acceso y refresco.
Tipos de concesión admitidos por Auris
OAuth 2.0 define varios “grant types” — flujos para obtener tokens según el tipo de cliente y caso de uso.
1. Authorization Code + PKCE (Recomendado)
El flujo estándar para aplicaciones orientadas al usuario (web apps, apps móviles, SPAs, CLIs con redirección al navegador). PKCE (Proof Key for Code Exchange, RFC 7636) se añade para proteger contra ataques de interceptación de código.
Cuándo usarlo: Cualquier aplicación donde un usuario real inicia sesión de forma interactiva.
2. Client Credentials (M2M)
Para comunicación servidor a servidor sin usuario involucrado. El cliente autentica directamente con su client_id y client_secret.
Cuándo usarlo: Servicios backend, trabajos cron, pipelines CI/CD que necesitan llamar a la API de Auris.
3. Device Authorization Grant (RFC 8628)
Para dispositivos con capacidades de entrada limitadas (smart TVs, CLIs, dispositivos IoT). El dispositivo muestra un código; el usuario lo introduce en otro dispositivo.
Cuándo usarlo: CLIs, smart TVs, consolas de juegos, dispositivos IoT.
4. CIBA (Client Initiated Backchannel Authentication)
Para escenarios donde el iniciador y el autenticador son personas diferentes (centros de llamadas, terminales de pago, pagos con altavoz inteligente).
Cuándo usarlo: Verificación en centros de llamadas, terminales de pago, aprobaciones de transacciones bancarias.
El flujo Resource Owner Password Credentials (ROPC) no está admitido en Auris. Es inherentemente inseguro (expone las credenciales del usuario al cliente) y el OAuth 2.0 Security Best Current Practice lo clasifica como obsoleto.
Scopes y claims
Los scopes controlan qué información se incluye en los tokens. Auris admite tanto scopes estándar de OIDC como scopes personalizados.
Scopes estándar de OIDC
| Scope | Claims incluidos |
|---|---|
openid | sub (requerido para OIDC) |
profile | name, given_name, family_name, picture |
email | email, email_verified |
phone | phone_number, phone_number_verified |
address | address (objeto estructurado) |
offline_access | Habilita la emisión de refresh tokens |
Claims personalizados
Los administradores pueden inyectar claims personalizados en los access tokens mediante la función Custom Claims de la Consola de Auris. Consulta la guía de custom claims para más detalles.