OAuth2.0 es un sistema de autorización de estándar abierto que se publicó en 2010, y corporaciones como Google y Twitter lo adoptaron rápidamente. Define cómo varios servicios pueden acceder de forma segura a los activos de datos (a través de la autenticación) sin revelar ninguna credencial. Esto a veces se denomina autorización delegada. Esto ayuda con la autorización de granularidad gruesa al proporcionar acceso limitado y regulado a ciertas API al crear aplicaciones.
OAuth es particularmente ventajoso ya que se puede incluir de manera eficiente en las actividades de desaprovisionamiento de identidad, que ahora son un componente esencial de cada configuración B2B.
Los flujos de OAuth son esencialmente métodos compatibles con OAuth para verificar los permisos y la información del propietario del recurso.
Hay distintos protocolos para varios flujos de OAuth. Hay flujos de OAuth que permiten a los clientes proporcionar credenciales directamente a la aplicación a través de una pantalla de inicio de sesión de OAuth. Algunos marcos de back-end incluso ayudan a la validación sin la interacción del cliente. Antes de entrar en los muchos tipos de flujos de OAuth, repasemos los conceptos básicos.
El protocolo OAuth utiliza los siguientes roles:
Continuando, ¿qué tal si nos sumergimos en los tipos de flujo de OAuth que debe tener en cuenta antes de que comencemos a trabajar con su caso de uso específico?
En el flujo de código de autorización, debe transmitir el secreto de cliente de la aplicación que se intercambia por un código de autorización o token. Este flujo difiere de la mayoría de los otros flujos en que primero requiere una aplicación para iniciar el navegador para comenzar el flujo.
Aplicaciones web y móviles del lado del servidor donde el código fuente no es público.
El flujo de credenciales de cliente permite que las aplicaciones pasen su secreto de cliente y su ID de cliente a un servidor de autorización para confirmar al usuario y devolver un token de autorización. Esto ocurre sin intervención del usuario.
Aplicaciones de máquina a máquina (M2M) (como demonios, administraciones de back-end y CLI). En estas aplicaciones, el flujo de autorización confirma y otorga el consentimiento en segundo plano sin involucrar al usuario, porque el "usuario" es con frecuencia una tarea de máquina o administración. No parece apropiado mostrar un indicador de inicio de sesión o utilizar inicios de sesión sociales.
En este flujo de OAuth, se solicita a los usuarios que envíen sus credenciales a través de un formulario, que luego se envía al backend y puede conservarse para uso futuro. Luego, se genera un token de acceso para el usuario. Por lo tanto, es importante que se pueda confiar completamente en la aplicación. Por lo tanto, este flujo generalmente no se recomienda.
Aplicaciones de alta confianza, donde no se pueden utilizar otros flujos basados en redireccionamientos.
Este flujo utiliza OIDC (OpenID Connect) para realizar un inicio de sesión web con funciones como WS-FED (Web Services Federation) y SAML (Secure Assertion Markup language). OpenID Connect es una capa de identidad sencilla construida sobre el protocolo OAuth. Permite a los Clientes autenticar a los Usuarios de Identidad Final en función de la autenticación del Servidor de Autorización y acceder a la información de perfil básica sobre los Usuarios Finales de manera interoperable y similar a REST.
OpenID Connect puede ser utilizado por clientes de varios tipos, incluidos clientes basados en web, móviles y JavaScript, para solicitar y recibir información sobre sesiones autenticadas y usuarios finales. El conjunto estándar es extensible, lo que permite a los participantes utilizar capacidades adicionales, como el cifrado de datos de identidad, el descubrimiento de proveedores de OpenID y cerrar sesión según sea necesario.
La aplicación web utiliza el front-end para solicitar y recibir tokens sin necesidad de llamadas o secretos adicionales al back-end. No necesita usar, mantener, adquirir o asegurar secretos en su aplicación usando este enfoque.
Aplicaciones que preferirían no gestionar los secretos localmente.
Este método es útil para las aplicaciones que necesitan almacenar de forma segura los secretos de los clientes. Proporciona acceso instantáneo a un token de identificación al mismo tiempo que permite la recuperación continua de tokens de acceso y actualización adicionales.
Esto es útil para las aplicaciones que requieren acceso inmediato a los datos del usuario, pero primero deben completar algún procesamiento antes de que se les conceda acceso a los recursos protegidos durante un período de tiempo prolongado.
Aplicaciones que requieren un acceso rápido a los datos del usuario pero que también necesitan utilizar estos datos de forma continua.
Puede usar este flujo para autenticar a los usuarios sin solicitar sus credenciales. Esto mejora la experiencia del usuario en dispositivos móviles, donde puede ser difícil ingresar las credenciales. Estas aplicaciones pueden iniciar el proceso de autorización y obtener un token proporcionando su ID de cliente al Flujo de autorización del dispositivo.
Aplicaciones en línea que funcionan en dispositivos con restricciones de entrada y brindan autenticación sin fricciones usando credenciales guardadas en el dispositivo.
Cuando los clientes públicos (como las aplicaciones nativas y de una sola página) solicitan tokens de acceso, se producen varios problemas de seguridad adicionales que el flujo de código de autorización no puede gestionar por sí solo, incluidos los siguientes:
Aplicaciones nativas
Aplicaciones de una sola página
Dadas estas circunstancias, OAuth 2.0 incluye una versión del flujo de código de autorización que emplea una clave de prueba para intercambio de código (PKCE).
El flujo de código de autorización mejorado por PKCE proporciona un secreto producido por la aplicación que llama que puede ser confirmado por el servidor de autorización llamado Verificador de código . Además, la aplicación de la persona que llama genera un valor de transformación del verificador de código llamado Code Challenge y lo entrega a través de HTTPS para obtener un código de autorización. Un atacante malicioso solo puede interceptar el Código de autorización y cambiarlo por un token si el Verificador de código no está presente.
Aplicaciones que deben servir a consumidores públicos desconocidos que pueden presentar riesgos de seguridad adicionales que el Auth Code Flow no maneja.
Como se habrá imaginado, los flujos de OAuth deben elegirse cuidadosamente para mejorar su caso de uso y abordar desafíos específicos. Por ejemplo, puede tener una sola aplicación que requiera tokens de acceso para muchos servidores de activos. Se requerirán varias llamadas para/aprobar.
Los flujos de OAuth son un método para recibir tokens de acceso, y el flujo apropiado para su caso de uso se decide según el tipo de aplicación. Otras consideraciones a tener en cuenta son el nivel de confianza en la aplicación y la experiencia de usuario prevista.
Hoy en día, tomar la decisión equivocada puede tener serias ramificaciones de seguridad y consistencia.