¿Qué es OAuth? Acceso delegado, tokens y flujos PKCE

Scrapeless Agent Browser admite navegación en el navegador y flujos de trabajo basados en sesión, mientras que los permisos de OAuth siguen siendo responsabilidad de la aplicación y del servidor de autorización.

OAuth es un framework para la autorización delegada

OAuth es un framework de autorización que permite a una aplicación obtener acceso limitado a recursos protegidos sin recopilar la contraseña del propietario del recurso para esos recursos. Un usuario puede autorizar, por ejemplo, que una herramienta de programación lea un calendario, mientras que el servicio de calendario controla las operaciones permitidas. La herramienta de programación recibe una credencial para ese acceso en lugar de la contraseña reutilizable del usuario.

El framework de autorización OAuth define los roles y las interacciones principales. El propietario del recurso controla el recurso correspondiente, la aplicación cliente solicita acceso, el servidor de autorización concede credenciales según su política y el servidor de recursos aloja la API protegida. Una organización puede operar ambos roles de servidor, pero mantener los roles distintos ayuda a explicar dónde se producen la autenticación, las decisiones de permiso y la validación de tokens.

Una concesión de token es más limitada que un permiso general para operar una cuenta. El acceso puede restringirse por alcance, recurso previsto, duración y la política del servidor de autorización. El servidor de recursos sigue verificando si la operación está permitida. Una pantalla de consentimiento describe el acceso solicitado, mientras que la credencial realmente concedida y la aplicación de políticas por parte del servidor determinan lo que la aplicación puede hacer después del consentimiento.

Autorización y autenticación responden a preguntas diferentes

La autorización determina a qué acceso puede acceder una aplicación; la autenticación establece una identidad en un contexto concreto. OAuth puede implicar que un usuario inicie sesión en el servidor de autorización, pero esa interacción no proporciona automáticamente al cliente una aserción de identidad estandarizada adecuada para su propio sistema de inicio de sesión. Tratar un token de acceso arbitrario como prueba de inicio de sesión puede crear problemas de sustitución de token y de audiencia.

La capa de identidad OpenID Connect añade autenticación sobre OAuth y define un token de ID que el cliente puede validar. Un token de acceso está destinado a un servicio de recursos, mientras que un token de ID se ocupa del contexto de autenticación del cliente. La distinción es visible en los estándares y debería seguir siendo visible en el diseño de la aplicación. Enviar un token de ID a una API no relacionada no es equivalente a presentar el token de acceso correcto.

Para un producto de inicio de sesión, selecciona una integración de proveedor que admita explícitamente el protocolo de identidad requerido y valida sus tokens utilizando ese protocolo. Para el acceso delegado a API, solicita los permisos mínimos apropiados y envía la credencial de acceso resultante solo a su servicio previsto. Un único botón orientado al usuario puede ocultar ambos flujos de trabajo, así que inspecciona el contrato real en lugar de denominar a cada acción de inicio de sesión social simplemente inicio de sesión con OAuth.

Un código de autorización separa el consentimiento en el navegador del uso del token

El flujo de código de autorización dirige al usuario a través del servidor de autorización, que autentica al usuario según sea necesario y evalúa la solicitud de acceso. Tras la aprobación, el navegador vuelve a la ubicación de redirección registrada del cliente con un código de autorización de corta duración. El cliente intercambia entonces ese código en el endpoint de token utilizando los parámetros y la autenticación apropiados para su tipo de cliente.

Un código no es la credencial de API utilizada para leer entradas de calendario u otros registros protegidos. Su propósito es conectar la interacción de autorización de canal frontal con el intercambio de token posterior. Mantén estricta la validación del URI de redirección y vincula la respuesta con la transacción que inició el cliente. Un callback recibido en un origen inesperado o sin el contexto de transacción esperado no debe convertirse en una sesión de aplicación autenticada.

Un registro de cliente describe detalles como sus ubicaciones de redirección y las concesiones permitidas. Una aplicación de servidor que puede proteger credenciales y una aplicación pública entregada por navegador tienen capacidades diferentes. No copies un secreto de cliente del lado servidor en JavaScript descargable. El modelo de distribución de la aplicación determina si ese valor puede mantenerse en confidencialidad, independientemente de la etiqueta que se le asigne en un panel de control.

PKCE protege el intercambio de código

PKCE, o Proof Key for Code Exchange, vincula la solicitud de autorización y el intercambio de token utilizando un verificador específico de la transacción. El cliente deriva un desafío a partir del verificador e incluye el desafío en la solicitud de autorización. En el endpoint de token proporciona el verificador, lo que permite al servidor confirmar que el intercambio pertenece a la misma transacción inicial.

El mecanismo PKCE aborda la interceptación de códigos de autorización. PKCE no convierte una aplicación pública en un cliente confidencial, y el verificador no es una contraseña de cliente permanente. Genéralo y consérvalo dentro de la transacción específica, mantenlo protegido y utiliza un método de desafío compatible que no exponga el verificador en la solicitud de autorización.

Las mejores prácticas de seguridad OAuth actuales requiere PKCE para clientes públicos en el flujo de código de autorización y lo recomienda para clientes confidenciales. También aborda la coincidencia exacta de redirecciones, la inyección de código y la filtración de tokens. Aplica esos requisitos mediante una implementación de OAuth mantenida en lugar de armar un flujo a partir de fragmentos sueltamente relacionados. Las bibliotecas correctas aún necesitan una configuración correcta de emisor, redirección y recursos.

Los tokens de acceso y los tokens de actualización tienen ciclos de vida separados

Un token de acceso contiene o hace referencia a la autorización necesaria para un servicio de recursos. Su formato no está definido por el marco general de OAuth: un servicio puede usar un valor opaco o un token estructurado. El cliente debe basarse en los campos de respuesta documentados y en los requisitos del recurso, en lugar de asumir que cada token de acceso es un JSON Web Token legible.

Un token de actualización es una credencial diferente que se usa con el servidor de autorización para obtener tokens de acceso. No debe enviarse a la API de recursos habitual. Si el servidor emite uno, cuánto tiempo sigue siendo válido y qué protecciones se aplican dependen del cliente y de la política del proveedor. Protégelo como un secreto valioso porque su ciclo de vida puede extenderse más allá del de un solo token de acceso.

La revocación también tiene una interfaz definida en lugar de estar implícita al eliminar una cadena local. Mecanismo de revocación de tokens OAuth permite que un cliente notifique al servidor de autorización que un token ya no es necesario. El cierre de sesión local, la revocación de concesiones y la finalización de cada sesión de aplicación pueden tener efectos diferentes. Documenta esos efectos para que los usuarios comprendan qué es lo que realmente cambia al desconectar una integración.

Alcance, público y la política del servidor limitan el acceso

Los ámbitos describen las capacidades solicitadas u otorgadas dentro del vocabulario del sistema de autorización. Sus nombres y significados pertenecen al proveedor. Un ámbito orientado a la lectura aún puede exponer registros sensibles, así que solicita solo lo que requiere la funcionalidad del producto y explica por qué. Una aplicación no debería pedir permisos amplios de escritura solo porque eso facilite el desarrollo futuro.

El recurso o la audiencia prevista constituyen otro límite. Un token emitido para un servicio no debe aceptarse como autorización intercambiable en otro servicio. Los servidores de recursos deben validar el emisor pertinente, la audiencia, la caducidad y los detalles de autorización utilizando el mecanismo de tokens seleccionado. Una firma válida por sí sola no establece que una credencial sea adecuada para la operación solicitada.

Los flujos de credenciales de cliente abordan el acceso de la aplicación en contextos que no representan el consentimiento delegado de un usuario. Los flujos orientados a dispositivos abordan otras restricciones de interacción. Elija una concesión compatible con el tipo de aplicación real en lugar de forzar todos los productos a través de un único flujo familiar. La presencia de OAuth en la documentación de un servicio no significa que todos los tipos de concesión, alcance o cliente estén disponibles para todas las cuentas.

Mantener el estado del navegador separado de las credenciales de OAuth

Las cookies del navegador, una sesión de aplicación y las credenciales OAuth son preocupaciones de implementación relacionadas pero con ciclos de vida diferentes. Un navegador puede permanecer con la sesión iniciada mientras un token de API expira, y una aplicación puede mantener un token delegado válido después de que se cierre una vista específica del navegador. Diagnostica los errores de permisos en el componente que posee la credencial correspondiente en lugar de copiar el estado del navegador a servicios no relacionados.

El Requisitos para el manejo de claves de la API de Scrapeless describa una credencial separada utilizada para acceder a los productos de Scrapeless. Una clave de API de Scrapeless no es un token de acceso OAuth para el sitio web de destino. El relacionado Métodos de autenticación de API ayudar a distinguir los esquemas de credenciales, y Precios sin scraping cubre el uso del servicio en lugar de los derechos de autorización de terceros.

Revisar una integración delegada antes de ampliarla

Una integración delegada debe tener un inventario de permisos claro. Registra el emisor, los recursos previstos, los alcances solicitados, el tipo de cliente, las ubicaciones de redirección, el almacenamiento de credenciales y el comportamiento de desconexión. Separa la telemetría ordinaria de la aplicación de los datos de solicitudes que portan tokens para que los registros rutinarios no se conviertan en un almacén de credenciales sin control. Prueba los límites de permisos con cuentas autorizadas y niveles de acceso documentados.

Una integración hipotética de calendario puede comenzar con acceso de solo lectura para una función aprobada por el usuario. Sus criterios de aceptación deben incluir la cuenta correcta, los recursos de calendario permitidos, una ruta de desconexión funcional y la ausencia de secretos en los registros visibles para el cliente. Amplía los permisos solo cuando una función concreta los requiera. Esa disciplina hace que la solicitud de consentimiento sea más fácil de explicar y limita las consecuencias de una exposición de credenciales.

Conclusión

OAuth delega acceso específico mediante roles definidos, credenciales y la política del servidor. Elige el flujo según el tipo real de cliente, usa PKCE cuando se requiera y mantén las aserciones de identidad separadas de los tokens de acceso a recursos. Una integración mantenible deja claros sus ámbitos (scopes), límites de almacenamiento y comportamiento de desconexión antes de manejar datos sensibles de cuentas.