¿Qué es OAuth? OAuth 2.0 explicado
OAuth 2.0 es un marco de autorización que permite a una aplicación obtener acceso limitado a recursos protegidos sin utilizar directamente las credenciales del propietario del recurso. El proceso utiliza componentes como clientes, servidores de autorización, servidores de recursos, authorization codes y access tokens para controlar el acceso.
¿Qué es OAuth?
OAuth 2.0 es un marco de autorización que permite que una aplicación obtenga acceso limitado a recursos protegidos en nombre de un usuario o cliente, sin que la aplicación necesite utilizar directamente las credenciales del propietario del recurso.
OAuth utiliza elementos como el authorization server, el resource server, el authorization code y el access token. OAuth no es por sí mismo un protocolo de autenticación de identidad; para ese objetivo suele utilizarse OpenID Connect sobre OAuth 2.0.
¿Cómo funciona OAuth 2.0?
OAuth separa la autorización de las credenciales principales y permite emitir tokens con acceso limitado a recursos protegidos.
El cliente solicita autorización
Una aplicación cliente solicita permiso para acceder a determinados recursos que pertenecen a un usuario o que están protegidos por un servidor.
El usuario concede acceso
El propietario del recurso interactúa con el servidor de autorización y puede aprobar el acceso solicitado según los permisos y alcances presentados.
Se entrega un token
Después del flujo correspondiente, el cliente obtiene un access token que puede presentar ante el servidor de recursos para acceder a los recursos permitidos.
OAuth no significa simplemente iniciar sesión con otra cuenta
OAuth está orientado principalmente a la autorización de acceso a recursos, mientras que la autenticación de identidad es un problema diferente.
¿A qué puede acceder una aplicación?
OAuth permite delegar acceso limitado a recursos protegidos mediante tokens y permisos definidos.
¿Quién eres?
La autenticación comprueba la identidad de la persona, dispositivo o servicio que intenta acceder.
Identidad sobre OAuth
OpenID Connect utiliza OAuth 2.0 como base y añade mecanismos destinados a comunicar información verificable sobre la identidad del usuario.
Principales componentes de OAuth 2.0
| Componente | Función | Ejemplo | Característica |
|---|---|---|---|
| Resource Owner | Controla el recurso protegido. | Usuario. | Puede conceder acceso a una aplicación. |
| Client | Solicita acceso al recurso. | Aplicación web o móvil. | Actúa en nombre del propietario o bajo sus propios permisos. |
| Authorization Server | Gestiona la autorización. | Proveedor de identidad o autorización. | Puede emitir authorization codes y tokens. |
| Resource Server | Aloja los recursos protegidos. | API. | Valida el access token recibido. |
| Access Token | Representa acceso autorizado. | Token enviado a una API. | Puede tener alcance y tiempo de validez. |
¿Qué es un cliente en OAuth?
El cliente es la aplicación que solicita acceso a un recurso protegido mediante el flujo de autorización.
Aplicación web
Un sitio web puede actuar como cliente cuando necesita acceder a recursos ofrecidos por otro servicio en nombre del usuario.
Aplicación móvil
Una aplicación móvil también puede actuar como cliente y solicitar autorización para utilizar determinados recursos disponibles mediante APIs.
Cliente no significa usuario
En OAuth, el cliente es el software que solicita acceso. El resource owner es quien controla el recurso protegido y puede autorizar ese acceso.
¿Qué es un Authorization Server?
El authorization server es el componente que gestiona el proceso mediante el cual un cliente obtiene autorización y recibe las credenciales correspondientes.
Solicitud
El cliente inicia el flujo solicitando autorización con los parámetros requeridos por el servidor.
Consentimiento
Cuando corresponde, el propietario del recurso interactúa con el servidor y decide si concede el acceso solicitado.
Emisión del token
El servidor puede emitir un authorization code, un access token u otras credenciales dependiendo del flujo y del cliente.
¿Qué es un Authorization Code?
El authorization code es una credencial temporal que puede emitir el servidor de autorización después de que el usuario haya completado el flujo correspondiente.
Código temporal
El código está diseñado para utilizarse durante un periodo limitado y puede intercambiarse por un access token.
Redirección
En el flujo de authorization code, el servidor de autorización puede devolver el código al cliente mediante una redirección hacia el redirect URI registrado.
Intercambio
El cliente utiliza el authorization code en el token endpoint para obtener los tokens que correspondan al flujo autorizado.
¿Qué es un Access Token?
Un access token es una credencial que el cliente puede presentar ante un resource server para solicitar acceso a recursos protegidos.
Acceso limitado
El token puede representar un acceso limitado a determinados recursos o acciones, de acuerdo con la autorización concedida.
API
Una aplicación puede enviar el access token junto con una solicitud a una API y el servidor de recursos puede validarlo antes de procesar la petición.
Vigencia
Los access tokens pueden tener un periodo de validez limitado según la implementación y las políticas del sistema.
¿Qué son los scopes en OAuth?
Los scopes permiten expresar el alcance del acceso solicitado y ayudan a indicar qué recursos o capacidades necesita una aplicación.
Acceso limitado
Una aplicación puede solicitar solamente los alcances necesarios para la tarea que pretende realizar, en lugar de recibir automáticamente acceso ilimitado.
Consentimiento
Los scopes pueden formar parte de la información mostrada al usuario cuando el flujo requiere que este apruebe el acceso solicitado.
Permisos del token
El access token emitido puede quedar asociado con los permisos o alcances concedidos durante el proceso de autorización.
¿Qué es un Refresh Token?
Un refresh token es una credencial utilizada en determinados flujos para solicitar un nuevo access token cuando el anterior deja de ser válido.
Access token
El access token se utiliza para solicitar acceso a recursos protegidos durante el periodo en que es válido.
Renovación
El refresh token puede permitir obtener un nuevo access token sin repetir necesariamente toda la interacción inicial con el usuario.
Protección
Un refresh token debe tratarse como una credencial sensible, especialmente cuando tiene una vigencia mayor que el access token asociado.
¿Cuál es la diferencia entre OAuth y autenticación?
OAuth está diseñado como un marco de autorización. Su propósito principal es permitir que una aplicación obtenga acceso limitado a recursos protegidos.
OAuth
OAuth responde principalmente a una pregunta relacionada con los permisos: qué acceso puede obtener una aplicación sobre determinados recursos.
Autenticación
La autenticación busca comprobar la identidad de la persona, dispositivo o servicio que está realizando el acceso.
OpenID Connect
OpenID Connect añade una capa de identidad sobre OAuth 2.0 y permite que una aplicación obtenga información verificable sobre el usuario autenticado.
¿Qué diferencia hay entre OAuth y OpenID Connect?
OAuth 2.0 proporciona un marco para autorización, mientras que OpenID Connect utiliza OAuth 2.0 como base y añade mecanismos para comunicar la identidad del usuario.
OAuth 2.0
Permite que un cliente obtenga acceso limitado a recursos protegidos mediante tokens y los permisos correspondientes.
OpenID Connect
Permite que una aplicación compruebe y reciba información verificable sobre la identidad del usuario mediante mecanismos específicos como el ID Token.
No son sinónimos
Utilizar OAuth no significa automáticamente que una aplicación tenga implementada autenticación de identidad. Cuando se necesita esa función, OpenID Connect proporciona el protocolo específico para ello.
¿Por qué la seguridad de OAuth es importante?
Un flujo OAuth mal implementado puede exponer códigos, tokens, redirecciones o credenciales y permitir accesos no autorizados a recursos protegidos.
Redirect URI
Los redirect URI forman parte fundamental del flujo y deben configurarse y validarse correctamente para evitar que las credenciales del proceso sean enviadas a destinos no autorizados.
Tokens
Los access tokens y refresh tokens deben protegerse como credenciales sensibles cuando proporcionan acceso a recursos protegidos.
Transporte seguro
Los flujos OAuth deben implementarse sobre canales seguros y utilizando las recomendaciones actuales aplicables al tipo de cliente y entorno.
¿Qué es PKCE en OAuth?
PKCE significa Proof Key for Code Exchange y añade una comprobación al flujo de authorization code para vincular el intercambio del código con el cliente que inició la solicitud.
Code verifier
El cliente genera un valor secreto denominado code verifier antes de iniciar el flujo y utiliza una transformación de ese valor durante la solicitud inicial.
Authorization code
Después de recibir el authorization code, el cliente presenta el code verifier durante el intercambio para demostrar que corresponde con la solicitud original.
Protección adicional
PKCE ayuda a proteger el intercambio del authorization code frente a determinados escenarios en los que un código podría ser interceptado.
¿Cómo se utiliza OAuth en una API?
Una aplicación puede utilizar OAuth para obtener un access token y posteriormente presentarlo al solicitar recursos protegidos de una API.
Solicitud
El cliente realiza una solicitud al recurso protegido incluyendo el mecanismo de autenticación definido por la API para presentar el access token.
Validación
El resource server valida el token y comprueba las condiciones necesarias antes de entregar el recurso solicitado.
Scopes
La API puede utilizar los scopes asociados con el token para determinar si el cliente dispone del alcance necesario para ejecutar una operación.
¿OAuth garantiza que una aplicación sea segura?
No. OAuth proporciona un marco de autorización, pero la seguridad final depende de la implementación, la configuración de clientes, tokens, redirecciones, scopes y otros componentes.
Implementación incorrecta
Una aplicación puede introducir vulnerabilidades aunque utilice OAuth si administra incorrectamente sus tokens, redirect URI o credenciales.
Permisos excesivos
Solicitar más scopes de los necesarios puede conceder a una aplicación un nivel de acceso superior al requerido para su función.
Gestión de credenciales
Los authorization codes, access tokens, refresh tokens y secretos de cliente deben manejarse según el tipo de aplicación y las recomendaciones de seguridad correspondientes.
¿Qué debe configurarse en una integración OAuth?
Una integración OAuth requiere definir correctamente los elementos que participan en el flujo y los recursos que la aplicación podrá solicitar.
Client ID
El authorization server identifica al cliente mediante un client identifier asociado con el registro de la aplicación.
Redirect URI
La aplicación debe utilizar una dirección de redirección configurada para recibir la respuesta del flujo de autorización.
Scopes
Los scopes deben limitarse a los permisos que realmente necesita la aplicación para realizar su función.
OAuth: conceptos principales
| Concepto | Significado | Ejemplo | Función |
|---|---|---|---|
| OAuth 2.0 | Marco de autorización. | Aplicación que accede a una API. | Delegar acceso limitado a recursos. |
| Authorization Code | Código temporal del flujo. | Código recibido mediante redirección. | Obtener tokens mediante el token endpoint. |
| Access Token | Credencial de acceso. | Token enviado a una API. | Acceder a recursos protegidos. |
| Refresh Token | Credencial para renovar acceso. | Solicitud de nuevo access token. | Renovar credenciales de acceso. |
| Scope | Alcance solicitado o concedido. | Permiso sobre un recurso. | Limitar el acceso disponible. |
Guías relacionadas sobre autenticación y seguridad
Elige el tema que quieras profundizar:
Preguntas frecuentes sobre OAuth
OAuth 2.0 es un marco de autorización que permite a una aplicación obtener acceso limitado a recursos protegidos sin utilizar directamente las credenciales del propietario del recurso.
Sirve para delegar acceso limitado a recursos protegidos mediante flujos de autorización y tokens de acceso.
OAuth está diseñado principalmente para autorización. Para autenticación de identidad sobre OAuth 2.0 se utiliza normalmente OpenID Connect.
Es una credencial que el cliente puede presentar ante un servidor de recursos para solicitar acceso a recursos protegidos.
Es un código temporal que puede emitir el servidor de autorización y que posteriormente puede intercambiarse por tokens mediante el token endpoint.
Los scopes expresan el alcance del acceso solicitado o concedido y permiten limitar los recursos o capacidades disponibles para una aplicación.
Es una credencial que puede utilizarse en determinados flujos para solicitar un nuevo access token cuando el anterior deja de ser válido.
OAuth 2.0 es un marco de autorización, mientras que OpenID Connect utiliza OAuth 2.0 como base y añade mecanismos para comunicar información verificable sobre la identidad del usuario.
¿Qué es un token de autenticación?
Continúa aprendiendo sobre seguridad de aplicaciones y descubre cómo funcionan los tokens utilizados para representar sesiones y credenciales.
Ver guía →