OAuth2 y OpenID Connect para APIs

OAuth2 permite acceso autorizado a APIs. OpenID Connect añade una capa de identidad estándar para autenticar usuarios.

Descripción compacta

OAuth2 es un framework de autorización ampliamente utilizado que permite a las aplicaciones acceder a recursos en nombre de un usuario sin recibir su contraseña directamente. OpenID Connect es una capa de identidad que se construye sobre OAuth2 y utiliza ID Tokens para confirmar la autenticación del usuario. Juntos forman el fundamento del Single Sign-On moderno y la seguridad de APIs. Los conceptos clave incluyen Authorization Server, Resource Server, Client, Access Token, ID Token, Scopes, Refresh Token y diferentes flujos como Authorization Code Flow con PKCE. Una implementación correcta es esencial para prevenir robo de tokens, ataques man-in-the-middle y acceso no autorizado. OAuth2 y OpenID Connect se usan hoy en día en casi todas las aplicaciones web, móviles y en la nube.

Componentes principales

Authorization Server

El Authorization Server es la entidad central que emite tokens. Autentica al usuario, solicita consentimiento y expide Access Token, opcionalmente ID Token y Refresh Token. Keycloak, Auth0, Okta y Azure AD son Authorization Servers conocidos.

Resource Server

El Resource Server es la API que proporciona recursos protegidos. Valida el Access Token y decide si la solicitud está permitida basándose en los scopes y claims. El Resource Server no conoce al usuario directamente, solo la información contenida en el token.

Client

El Client es la aplicación que desea acceder a la API en nombre del usuario. Los clientes pueden ser confidenciales, como un servidor backend, o públicos, como una aplicación móvil o una Single-Page-Application. Los clientes públicos requieren medidas de protección especiales como PKCE.

Access Token

El Access Token es un token de corta duración que autoriza al cliente a acceder a recursos protegidos. Se transmite en el header Authorization como Bearer Token. Los Access Tokens nunca deben ser válidos más tiempo del necesario y siempre deben transmitirse sobre HTTPS.

ID Token

El ID Token es emitido por OpenID Connect y contiene información de identidad del usuario, como sub, name y email. Es un JWT y se utiliza para autenticación, no para acceso a APIs. El acceso a APIs se realiza con el Access Token.

Refresh Token

Los Refresh Tokens son tokens de larga duración que permiten al cliente solicitar un nuevo Access Token sin pedir nuevamente la contraseña al usuario. Deben protegerse especialmente y ser revocables si se sospecha compromiso.

Scopes

Los scopes definen qué permisos solicita un cliente. Ejemplos incluyen read, write o profile. El usuario o el Authorization Server decide qué scopes se conceden. El Resource Server verifica si la acción solicitada está dentro del alcance del token.

Authorization Code Flow

Authorization Code Flow es el flujo OAuth2 más seguro y común. El usuario se redirige al Authorization Server, se autentica y el servidor devuelve un código a la aplicación cliente. El cliente intercambia el código por Access Token e ID Token.

PKCE

PKCE significa Proof Key for Code Exchange y es una extensión de Authorization Code Flow. Protege a clientes públicos como aplicaciones móviles o Single-Page-Applications contra ataques de interceptación de código. El cliente genera un verificador de código aleatorio y envía su hash como code challenge.

Client Credentials Flow

Client Credentials Flow se utiliza para comunicación máquina a máquina cuando no hay usuario involucrado. El cliente se autentica con Client ID y Client Secret directamente ante el Authorization Server y obtiene un Access Token.

Implicit Flow y Password Flow

Implicit Flow y Resource Owner Password Credentials Flow se consideran obsoletos y no deben usarse por los riesgos de seguridad que conllevan. Las aplicaciones modernas utilizan Authorization Code Flow con PKCE en su lugar.

Validación de tokens

El Resource Server debe validar el Access Token antes de procesar una solicitud. Para ello verifica firma, tiempo de expiración, emisor, audience y scopes. Los JWTs autofirmados se validan con la clave pública del Authorization Server, mientras que los tokens opacos se validan mediante introspection.

Logout y gestión de sesiones

OpenID Connect define diferentes mecanismos de logout, incluyendo RP-Initiated Logout, Back-Channel Logout y Front-Channel Logout. Permiten terminar sesiones centralmente e invalidar tokens.

Ejemplo práctico

Una aplicación móvil desea acceder a una API de perfil de usuario. Utiliza Authorization Code Flow con PKCE.

Paso 1: La aplicación genera un code verifier y una code challenge:

code_verifier = random_string(128)
code_challenge = BASE64URL(SHA256(code_verifier))

Paso 2: La aplicación redirige al usuario al Authorization Server:

https://auth.example.com/authorize?
  response_type=code
  &client_id=mobile-app
  &redirect_uri=app://callback
  &scope=openid profile read:profile
  &code_challenge=abc123
  &code_challenge_method=S256
  &state=xyz789

Paso 3: Tras autenticarse y consentir, la aplicación recibe un código de autorización:

app://callback?code=AUTH_CODE&state=xyz789

Paso 4: La aplicación intercambia el código por tokens:

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE
&redirect_uri=app://callback
&client_id=mobile-app
&code_verifier=CODE_VERIFIER

Paso 5: La aplicación invoca la API:

GET /api/v1/profile
Authorization: Bearer ACCESS_TOKEN

PKCE garantiza que el flujo sea seguro incluso para clientes públicos, porque un código interceptado no puede ser intercambiado sin el code verifier.

Preguntas frecuentes: OAuth2 y OpenID Connect

1. ¿Qué es OAuth2?

OAuth2 es un framework de autorización que permite a las aplicaciones acceder a recursos en nombre de un usuario sin conocer la contraseña del usuario.

2. ¿Qué es OpenID Connect?

OpenID Connect es una capa de identidad basada en OAuth2. Permite autenticar a un usuario y proporciona un ID Token con información de identidad.

3. ¿Cuál es la diferencia entre Access Token e ID Token?

El Access Token se utiliza para acceder a APIs protegidas. El ID Token sirve para autenticación y contiene información de identidad del usuario.

4. ¿Qué es PKCE?

PKCE significa Proof Key for Code Exchange. Es una extensión de Authorization Code Flow que protege a clientes públicos como aplicaciones móviles y Single-Page-Applications contra ataques de interceptación de código.

5. ¿Qué son los scopes?

Los scopes definen los permisos que solicita un cliente. Se especifican ante el Authorization Server y se incluyen en el Access Token. El Resource Server los verifica antes de conceder acceso.

6. ¿Qué es un Refresh Token?

Un Refresh Token es un token de larga duración que permite a un cliente solicitar un nuevo Access Token sin volver a autenticar al usuario. Los Refresh Tokens deben protegerse especialmente.

7. ¿Qué es Authorization Code Flow?

Authorization Code Flow es el flujo OAuth2 más común y seguro. El cliente recibe un código después de la autenticación del usuario e intercambia este código en el backend por tokens.

8. ¿Qué es Client Credentials Flow?

Client Credentials Flow se utiliza para comunicación máquina a máquina. El cliente se autentica directamente con Client ID y Client Secret y obtiene un Access Token.

9. ¿Por qué Implicit y Password Flow se consideran obsoletos?

Implicit y Password Flow conllevan riesgos de seguridad como exposición de tokens en el navegador o compartir contraseñas con terceros. Las aplicaciones modernas utilizan Authorization Code Flow con PKCE.

10. ¿Qué es Token Introspection?

Token Introspection es un endpoint del Authorization Server que permite a un Resource Server validar un token opaco. El servidor obtiene información sobre validez, expiración y scopes.

11. ¿Qué es un Audience Claim?

El Audience Claim en el token indica para cuál API o servicio está destinado el token. El Resource Server verifica si es la audience objetivo para prevenir abuso de tokens.

12. ¿Cómo se valida un JWT Access Token?

Un JWT Access Token se valida verificando firma, emisor, audience, tiempo de expiración y scopes. La firma se verifica con la clave pública del Authorization Server.

13. ¿Qué es Single Sign-On?

Single Sign-On permite a los usuarios autenticarse una sola vez y acceder a múltiples aplicaciones sin necesidad de autenticarse nuevamente. OpenID Connect es un protocolo común para esto.

14. ¿Qué es Back-Channel Logout?

Back-Channel Logout es un mecanismo de OpenID Connect en el que el Authorization Server notifica a las aplicaciones directamente mediante una llamada servidor a servidor que una sesión ha terminado.

15. ¿Cuáles son errores típicos en OAuth2?

Los errores típicos incluyen Access Tokens de larga duración, falta de PKCE en clientes públicos, falta de validación de audience, transmisión sin encriptar, Refresh Tokens de larga duración sin revocación y uso incorrecto de ID Tokens como Access Tokens.

Continúa con el camino de aprendizaje de API

El siguiente artículo en el camino de aprendizaje de API cubre JWT Token: Estructura, seguridad y uso correcto — construcción de JSON Web Tokens, procedimientos de firma y mejores prácticas de seguridad.

Fuentes

Recomendaciones de libros sobre seguridad de API

Si deseas profundizar en OAuth2, OpenID Connect y seguridad de API, te recomendamos los siguientes libros:

Keine Bücher für Kategorie "security" gefunden.

Täglicher Artikel