¿Qué es OAuth? Roles, Flujos, Tokens y Fundamentos de Seguridad

La API de Scrapeless Scraping utiliza una clave de API en el encabezado x-api-token, proporcionando un contraste concreto con el modelo de autorización delegada de OAuth.

¿Qué es OAuth?

OAuth es un marco para autorización delegada. Permite que una aplicación solicite acceso limitado a recursos protegidos sin pedir al usuario la contraseña del servicio que posee esos recursos. El usuario interactúa con el servidor de autorización, aprueba el acceso solicitado y el cliente recibe un token en lugar de las credenciales principales del usuario.

RFC 6749 define el marco de autorización OAuth 2.0.Describe roles, puntos finales de protocolo, concesiones de autorización, tokens de acceso y tokens de actualización. Documentos posteriores actualizan el marco y proporcionan orientación de seguridad para implementaciones actuales.

OAuth también puede autorizar a clientes de máquina actuando en su propio nombre. La concesión de credenciales del cliente está diseñada para un cliente confidencial que accede a recursos bajo una relación de servicio establecida. Ese flujo es diferente de un usuario que aprueba una aplicación de terceros.

Los Cuatro Roles de OAuth

Una organización puede operar tanto el servidor de autorización como el servidor de recursos, pero siguen siendo roles de protocolo separados. Mantener los roles claros ayuda a los equipos a colocar la validación y la política en el límite correcto.

Cómo Funciona el Flujo de Código de Autorización

1. El cliente crea una solicitud de autorización. Envía el navegador al punto final de autorización con un identificador de cliente, alcance solicitado, URI de redirección, estado y desafío PKCE.
2. El servidor de autorización maneja la interacción del usuario. Autentica al usuario cuando es necesario y muestra el acceso que se está solicitando.
3. El propietario del recurso otorga o niega el acceso. El consentimiento y la política determinan si se emite un código de autorización.
4. El navegador regresa a la URI de redirección registrada. La respuesta incluye el código de autorización y el valor de estado.
5. El cliente valida la respuesta. Compara el estado con el valor vinculado a la sesión del navegador iniciador.
6. El cliente intercambia el código. Llama al endpoint de token con el código y el verificador PKCE; un cliente confidencial también utiliza su método de autenticación aprobado.
7. El servidor de autorización emite tokens. La respuesta comúnmente incluye un token de acceso y puede incluir un token de actualización según la política del servidor.
8. El cliente llama al servidor de recursos. El servidor de recursos valida el token y aplica políticas de alcance, audiencia y nivel de recurso.

El código de autorización es una credencial intermedia, no el token API final. Enviar el token de acceso directamente a través de la respuesta de autorización visible al navegador lo expone a más superficies en el canal frontal. La práctica actual mantiene el intercambio del token de acceso en el endpoint de token y lo protege con PKCE y autenticación del cliente cuando es aplicable.

¿Qué es PKCE?

PKCE significa Proof Key for Code Exchange. El cliente genera un verificador de alta entropía para un intento de autorización y envía un desafío derivado con la solicitud de autorización. Durante el intercambio de códigos, el cliente presenta el verificador. El servidor de autorización vuelve a calcular el desafío y acepta el código solo cuando los valores coinciden.

RFC 7636 define PKCE.Se creó para proteger los códigos de autorización interceptados de redirecciones de cliente público, y la guía de seguridad actual lo aplica ampliamente a flujos de códigos de autorización. Utiliza el método de desafío seguro respaldado por el perfil estándar en lugar de una transformación de verificador simple.

PKCE no reemplaza el estado. PKCE vincula el intercambio de códigos a la instancia de cliente iniciadora. El estado vincula la respuesta de autorización a la interacción del navegador y ayuda a proteger contra la falsificación de solicitud entre sitios y la confusión en el manejo de sesiones del cliente.

Tokens de Acceso y Tokens de Actualización

Un token de acceso representa la autoridad otorgada a un cliente. El servidor de recursos lo utiliza para decidir si una solicitud puede acceder al recurso y operación solicitados. El token puede ser opaco, requiriendo introspección o búsqueda del lado del servidor, o auto contenido bajo un perfil de token firmado definido.

Un token de actualización permite a un cliente solicitar un nuevo token de acceso sin otra interacción del usuario. Normalmente se envía solo al servidor de autorización, no al servidor de recursos. Los tokens de actualización son credenciales valiosas de larga duración y necesitan almacenamiento protegido, vinculación del cliente, rotación o controles de reproducción definidos por el servidor, y soporte de revocación.

El formato del token es independiente del flujo de OAuth. OAuth no requiere JSON Web Tokens. Un token de acceso opaco puede ser preferible cuando importa la política central inmediata y la revocación. Un token auto contenido puede reducir las necesidades de búsqueda, pero requiere una validación cuidadosa del emisor, audiencia, firma, reclamos de tiempo y los algoritmos permitidos por el perfil.

Alcances, Audiencia y Consentimiento

Un alcance es una cadena definida por el servidor de autorización que representa un permiso o categoría de acceso. Un cliente solicita alcances, pero el servidor puede emitir menos autoridad basada en el consentimiento y la política. Los nombres de los alcances deben describir capacidades significativas en lugar de reflejar cada punto final interno.

La audiencia identifica el servidor de recursos o conjunto de recursos previsto. Un token emitido para una API no debe ser aceptado por una API no relacionada simplemente porque su firma es válida. Los servidores de recursos deben validar la audiencia y el emisor que esperan.

El consentimiento no es un sustituto de la política. Un usuario no debe poder otorgar autoridad que no posee. El servidor de autorización y el servidor de recursos aún aplican restricciones de inquilino, rol, propiedad, riesgo y nivel de recurso.

Clientes Públicos y Confidenciales

Un cliente confidencial puede proteger credenciales a través de un entorno controlado por su operador, como un servicio de backend. Un cliente público se ejecuta donde no se puede mantener un secreto, como un navegador o una aplicación instalada distribuida a los usuarios. Enviar el mismo secreto de cliente en cada copia de una aplicación pública no hace que esas copias sean confidenciales.

Los clientes públicos dependen de PKCE, manejo exacto de redirecciones, protecciones de plataforma y autoridad de token limitada en lugar de un secreto embebido compartido. Los clientes confidenciales utilizan un método de autenticación aprobado por el servidor de autorización en el endpoint de token y deben proteger esas credenciales a través de un ciclo de vida de secretos.

OAuth vs Claves API

Una clave API generalmente identifica un cliente o proyecto directamente. Funciona bien para una relación controlada de servidor a servidor donde el propietario de la cuenta aprovisiona la credencial. OAuth agrega un protocolo para obtener tokens bajo un otorgamiento, incluyendo acceso delegado por el usuario con consentimiento y alcances.

Utiliza una clave API cuando un servicio de backend accede a su propia cuenta y el modelo de clave del proveedor ofrece restricciones adecuadas. Utiliza OAuth cuando los clientes de terceros necesitan acceso limitado en nombre de los usuarios, cuando los permisos necesitan revocación independiente, o cuando un ecosistema requiere flujos de autorización estandarizados.

Ninguna opción es automáticamente segura. Las claves API necesitan almacenamiento protegido y restricciones. OAuth necesita validación correcta del endpoint, manejo de redirecciones, validación de tokens, diseño de alcances y decisiones del tipo de cliente.

OAuth vs OpenID Connect

OAuth autoriza el acceso a recursos. No define una declaración estándar que el cliente pueda tratar como la identidad de inicio de sesión del usuario. OpenID Connect agrega una capa de autenticación sobre OAuth e introduce el token ID, una afirmación firmada sobre el evento de autenticación y el sujeto.

Un cliente no debe tratar un token de acceso arbitrario de OAuth como prueba de inicio de sesión. Para el inicio de sesión, utiliza un flujo de OpenID Connect y valida el token ID de acuerdo con los metadatos y el perfil del proveedor, incluyendo emisor, audiencia, firma, reclamos de tiempo, nonce cuando se use, y la vinculación de la respuesta de autorización.

Guía de Seguridad Actual de OAuth

RFC 9700 proporciona la mejor práctica de seguridad actual de OAuth 2.0. Actualiza la guía de implementación basada en ataques y experiencia de implementación. Los nuevos sistemas deben usar flujos de código de autorización con PKCE, coincidencia exacta de URI de redirección, interacción segura del navegador y transporte de tokens protegido.

La concesión implícita expone tokens de acceso a través de la respuesta de autorización y no es el diseño preferido para nuevos clientes. La concesión de credenciales de contraseña del propietario del recurso le pide a un cliente que maneje la contraseña del usuario y no debe usarse. Estos patrones más antiguos pueden aparecer en sistemas heredados, pero copiarlos en una nueva implementación descarta límites más fuertes.

Errores Comunes de OAuth

• Llamar a la autenticación de OAuth. OAuth autoriza el acceso a la API; usa OpenID Connect para una capa de identidad de inicio de sesión estándar.
• Coincidencia suelta de URI de redirección. Aceptar solo URI de redirección registradas exactas según las reglas del perfil.
• Omitir la validación de estado. Vincular la respuesta a la sesión del navegador iniciador y rechazar discordancias.
• Omitir PKCE. Los clientes de código de autorización deben usar un verificador nuevo y un desafío seguro para cada solicitud.
• Aceptar cualquier token firmado. Los servidores de recursos deben validar el emisor, audiencia, tipo o perfil, tiempo, firma y afirmaciones de autorización.
• Ámbitos excesivos. Solicitar y emitir la autoridad más pequeña útil.
• Poner tokens en URLs. Usar encabezados de autorización a través de HTTPS para reducir la fuga a través de registros y superficies del navegador.

Casos de Uso de OAuth

Lista de Verificación de Implementación

1. Elegir la concesión para el cliente y el caso de uso. La delegación interactiva de usuarios y el acceso a servicios tienen diferentes límites de confianza.
2. Registrar URI de redirección exactos. Separar entornos y evitar redirigidores abiertos.
3. Usar código de autorización con PKCE. Generar un nuevo verificador y valor de estado para cada solicitud de autorización.
4. Validar cada respuesta. Verificar estado, metadatos del emisor donde sea aplicable, vinculación de código y campos de respuesta de token.
5. Proteger tokens. Mantenerlos fuera de URLs y registros, almacenarlos por el período necesario más corto y usar patrones de almacenamiento seguro en el navegador o servidor.
6. Hacer cumplir en el servidor de recursos. Validar el perfil del token, emisor, audiencia, fecha de caducidad, ámbito y política a nivel de recurso.
7. Planificar la revocación y la gestión de incidentes. Los usuarios y administradores necesitan una forma de eliminar concesiones y deshabilitar credenciales comprometidas.

Conclusión

OAuth separa las credenciales primarias de un usuario o servicio de los tokens limitados que un cliente utiliza en una API. Sus roles, concesiones, ámbitos y puntos finales crean un límite de autorización estándar, pero el protocolo sigue dependiendo de una implementación precisa. El código de autorización con PKCE, redirecciones exactas, tokens emitidos de manera restringida, validación correcta del servidor de recursos y OpenID Connect para el inicio de sesión proporcionan una base sólida para los sistemas actuales.