oauth oauth-2.0

oauth - ¿Cuál es la diferencia entre los 2 flujos de trabajo? ¿Cuándo usar el flujo de código de autorización?



oauth-2.0 (7)

Flujo implícito

Ventajas

  • Más simple de implementar

Desventajas

  • Fichas de acceso visibles para el navegador
  • El origen de los tokens de acceso no se puede determinar
  • Los tokens de acceso no pueden caducar (según la política de Google)

Flujo de código de autorización

Ventajas

  • Más seguro
  • Los tokens de acceso y los tokens de actualización se pueden crear solo si se conoce un secreto compartido
  • Se puede mejorar con nuevas características de seguridad y UX cuando estén disponibles

Desventajas

  • Debe implementar múltiples puntos finales de autenticación

Cita: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

OAuth 2.0 tiene múltiples flujos de trabajo. Tengo algunas preguntas con respecto a los dos.

  1. Flujo de código de autorización : el usuario inicia sesión desde la aplicación del cliente, el servidor de autorización devuelve un código de autorización a la aplicación. La aplicación intercambia el código de autorización para el token de acceso.
  2. Flujo de donaciones implícito : el usuario inicia sesión desde la aplicación del cliente, el servidor de autorización emite un token de acceso a la aplicación del cliente directamente.

¿Cuál es la diferencia entre los dos enfoques en términos de seguridad? ¿Cuál es más seguro y por qué?

No veo una razón por la cual se agregue un paso adicional (código de autorización de cambio para el token) en un flujo de trabajo cuando el servidor puede emitir directamente un token de acceso.

Diferentes sitios web dicen que el flujo de código de autorización se usa cuando la aplicación del cliente puede mantener las credenciales seguras. ¿Por qué?

Agregaré algo aquí que no creo que quede claro en las respuestas anteriores:

  • Authorization-Code-Flow permite que el token de acceso final nunca llegue y nunca se almacene en la máquina con el navegador / aplicación . El código de autorización temporal se entrega a la máquina con el navegador / aplicación, que luego se envía a un servidor. El servidor puede intercambiarlo con un token de acceso completo y tener acceso a las API, etc. El usuario con el navegador obtiene acceso a la API solo a través del servidor con el token.
  • El flujo implícito solo puede involucrar a dos partes, y el token de acceso final se almacena en el cliente con el navegador / aplicación. Si este navegador / aplicación está en peligro, su auth-token podría ser peligroso.

tl; dr no usa flujo implícito si no confía en que la máquina de los usuarios contenga tokens, pero confía en sus propios servidores.

Desde una perspectiva práctica (lo que yo entendí), la razón principal para tener flujo de código Authz es:

  1. Soporte para tokens de actualización (acceso a largo plazo por parte de las aplicaciones en nombre del usuario), no admitido de forma implícita: consulte: https://tools.ietf.org/html/rfc6749#section-4.2
  2. Soporte para la página de consentimiento, que es un lugar donde el propietario del recurso puede controlar qué acceso proporcionar (tipo de permisos / página de autorización que ve en google). Lo mismo no está allí en implícito. Ver la sección: https://tools.ietf.org/html/rfc6749#section-4.1 , punto (B)

"El servidor de autorización autentica al propietario del recurso (a través del agente de usuario) y establece si el propietario del recurso otorga o niega la solicitud de acceso del cliente"

Además de eso, mediante el uso de tokens de actualización, las aplicaciones pueden obtener acceso a largo plazo a los datos del usuario.

La concesión implícita es similar a la concesión del código de autorización con dos diferencias distintas.

Está destinado a ser utilizado por clientes basados ​​en agentes de usuario (por ejemplo, aplicaciones web de una sola página) que no pueden mantener en secreto a un cliente porque se puede acceder fácilmente a todo el código y el almacenamiento de la aplicación.

En segundo lugar, en lugar de que el servidor de autorización devuelva un código de autorización que se intercambia por un token de acceso, el servidor de autorización devuelve un token de acceso.

Encuentre los detalles aquí http://oauth2.thephpleague.com/authorization-server/which-grant/

La diferencia entre ambos es que:

  1. En Flujo implícito, el token se devuelve directamente a través de la URL de redireccionamiento con el signo "#" y esto se usa principalmente en clientes JavaScript o aplicaciones móviles que no tienen el lado del servidor, y el cliente no necesita proporcionar su secreto en algunas implementaciones .

  2. En el flujo del código de autorización, el código se devuelve con "?" para ser legible por el lado del servidor, entonces el lado del servidor debe proporcionar el secreto del cliente esta vez a la URL del token para obtener el token como objeto json del servidor de autorización. Se usa en caso de que tenga un servidor de aplicaciones que pueda manejar esto y almacene el token de usuario con su perfil en su propio sistema, y ​​que se use principalmente para aplicaciones móviles comunes.

así que depende de la naturaleza de su aplicación cliente, cuál es un "código de autorización" más seguro ya que solicita el secreto en el cliente y el token puede enviarse entre el servidor de autorización y la aplicación cliente en una conexión muy segura, y el proveedor de autorización puede restringir a algunos clientes para usar solo "Código de autorización" y no permitir Implicit

Permítanme resumir los puntos que aprendí de las respuestas anteriores y agregar algunos de mis propios entendimientos.

Flujo de código de autorización !!!

  • Si tiene un servidor de aplicaciones web que actúa como cliente de OAuth
  • Si quieres tener acceso de larga duración
  • Si quieres tener acceso sin conexión a los datos
  • cuando eres responsable de las llamadas de API que hace tu aplicación
  • Si no quieres filtrar tu token de OAuth
  • Si no desea que su aplicación se ejecute a través del flujo de autorización cada vez que necesite acceso a los datos. NOTA: el flujo de Otorgamiento implícito no entretiene el token de actualización, por lo que si el servidor de autorización expira los tokens de acceso con regularidad, su aplicación deberá ejecutar el flujo de autorización cada vez que necesite acceso.

¡Flujo de donaciones implícito!

  • Cuando no tiene un servidor de aplicaciones web para actuar como cliente de OAuth
  • Si no necesita acceso de larga duración, es decir, solo se requiere acceso temporal a los datos.
  • Si confía en el navegador donde se ejecuta su aplicación y existe una preocupación limitada de que el token de acceso se filtre a los usuarios que no son de confianza.

access_token es lo que necesita para llamar a un recurso protegido (una API). En el flujo de código de autorización hay 2 pasos para obtenerlo:

  1. El usuario debe autenticarse y devolver un code al consumidor API (llamado "Cliente").
  2. El "cliente" de la API (generalmente su servidor web) intercambia el code obtenido en el # 1 por un access_token , autenticándose con un client_id y client_secret
  3. Luego puede llamar a la API con access_token .

Entonces, hay una doble comprobación: el usuario que posee los recursos salió a la superficie a través de una API y el cliente que usa la API (por ejemplo, una aplicación web). Ambos están validados para que se otorgue acceso. Observe la naturaleza de "autorización" de OAuth aquí: el usuario otorga acceso a su recurso (a través del code devuelto después de la autenticación) a una aplicación, la aplicación obtiene un access_token y llama en nombre del usuario.

En el flujo implícito, el paso 2 se omite. Entonces, después de la autenticación del usuario, se devuelve un access_token directamente, que puede usar para acceder al recurso. La API no sabe quién llama a esa API. Cualquiera con el access_token puede, mientras que en el ejemplo anterior solo la aplicación web lo haría (sus funciones internas normalmente no son accesibles para nadie).

El flujo implícito se usa generalmente en escenarios donde no se recomienda el almacenamiento del client id y client secret (un dispositivo por ejemplo, aunque muchos lo hacen de todos modos). Eso es lo que significa el descargo de responsabilidad. Las personas tienen acceso al código del cliente y, por lo tanto, pueden obtener las credenciales y pretender convertirse en clientes de recursos. En el flujo implícito, todos los datos son volátiles y no hay nada almacenado en la aplicación.