Definición:
OAuth es un marco abierto de autorización que permite a una aplicación obtener acceso limitado a recursos protegidos de otro servicio sin recibir la contraseña de la persona usuaria. El acceso se representa mediante credenciales específicas y puede restringirse por alcance, duración y contexto.
Se utiliza habitualmente para conectar aplicaciones con una API. Cuando un servicio solicita permiso para consultar un calendario, publicar contenido o leer determinados datos de una cuenta, OAuth organiza la concesión y el uso de ese permiso. La persona se autentica ante el proveedor que controla el recurso, no ante la aplicación que solicita el acceso.
Índice de contenidos
Autorización y autenticación
OAuth responde principalmente a una pregunta de autorización: qué puede hacer una aplicación sobre unos recursos concretos. No define por sí solo cómo demostrar la identidad de una persona ni proporciona a la aplicación un perfil fiable del usuario.
La pantalla de inicio de sesión del proveedor puede formar parte de la experiencia, pero ese paso no convierte a OAuth en un protocolo de autenticación. Para iniciar sesión con una identidad federada suele utilizarse OpenID Connect, una capa de identidad construida sobre OAuth 2.0 que incorpora un ID Token y reglas para verificar al usuario.
Esta separación permite conceder acceso sin compartir credenciales. También hace posible revocar el permiso de una aplicación sin cambiar la contraseña ni retirar el acceso a las demás aplicaciones conectadas.
Participantes y flujo
Una operación OAuth coordina varias funciones. Un mismo sistema puede asumir más de una, pero cada papel mantiene una responsabilidad distinta:
- Propietario del recurso: Persona o entidad capaz de autorizar el acceso.
- Cliente: Aplicación que solicita permiso para actuar.
- Servidor de autorización: Sistema que obtiene la decisión y emite los tokens.
- Servidor de recursos: Servicio que protege la información o función solicitada.
En un flujo habitual, el cliente dirige al usuario al servidor de autorización. Allí se muestran el cliente y los permisos solicitados. Tras la decisión, el cliente recibe una credencial intermedia o un token según el flujo utilizado. El servidor de recursos valida después el token antes de responder a la petición HTTP.
La redirección evita que la aplicación cliente gestione la contraseña del proveedor. Sin embargo, el diseño sigue necesitando validar destinos, vincular cada respuesta con su solicitud y proteger las credenciales frente a filtraciones.
Tokens y alcance
El token de acceso representa la autorización concedida. El cliente lo presenta al servidor de recursos para realizar acciones permitidas durante su vigencia. Puede ser una cadena opaca o tener un formato estructurado; OAuth no exige que todos los tokens sean JWT.
El alcance, denominado scope, expresa los permisos solicitados o concedidos. Un proveedor puede separar, por ejemplo, la lectura de datos y su modificación. El servidor aplica sus propias políticas, por lo que el alcance pedido por el cliente no garantiza que se conceda íntegramente.
Un token de refresco puede permitir obtener nuevos tokens de acceso sin repetir toda la interacción con el usuario. No se envía a la API de recursos y requiere una protección más estricta. Su disponibilidad, duración, rotación y revocación dependen del servidor de autorización y del tipo de cliente.
Los tokens bearer permiten actuar a quien los posee mientras sigan siendo válidos. Por eso deben transmitirse mediante canales protegidos, almacenarse con cuidado y limitarse a los recursos necesarios.
Flujos de autorización
OAuth 2.0 admite distintos mecanismos para obtener autorización. La elección depende de si interviene una persona, de la capacidad del cliente para guardar secretos y de la relación entre los sistemas.
- Código de autorización: El cliente intercambia un código temporal por tokens. PKCE vincula ese intercambio a la solicitud inicial y protege frente a la interceptación del código.
- Credenciales de cliente: Una aplicación obtiene acceso en su propio nombre, sin representar a una persona.
- Concesiones específicas: Extensiones como Device Authorization cubren dispositivos con entrada o navegador limitados.
Las prácticas actuales desaconsejan el flujo implícito y prohíben utilizar la contraseña del usuario como concesión. También exigen coincidencias estrictas en las URI de redirección, protección contra falsificación de solicitudes y transporte cifrado. Estas medidas complementan el protocolo y reducen riesgos conocidos, pero no corrigen una implementación defectuosa de la aplicación o de la API REST.
Evolución del estándar
OAuth nació de un trabajo comunitario iniciado en 2006 para resolver la delegación de acceso entre servicios web. OAuth 1.0 se formalizó como RFC 5849 en 2010. OAuth 2.0 se publicó como RFC 6749 en 2012, sustituyó el protocolo anterior y definió un marco diferente, no compatible directamente con OAuth 1.0.
La especificación de 2012 se ha ampliado mediante RFC dedicadas a tokens, aplicaciones nativas, metadatos, revocación y otros escenarios. La práctica de seguridad RFC 9700, publicada en 2025, actualiza las recomendaciones a partir de amenazas e implementaciones observadas y deja obsoletos algunos modos de uso antiguos.
OAuth no hace que una integración sea segura de manera automática. La protección final depende de los permisos solicitados, la validación de redirecciones, la gestión de tokens y la aplicación coherente de las políticas por todos los participantes.