¿Cuál es el beneficio de OAuth “flujo de código de una sola vez (autenticación híbrida)”?

3

Con referencia a la omniauth-google-oauth2 gema que describe lo que denomina "Flujo de código único (Autenticación híbrida)" como tal:

  

Este flujo de autenticación híbrida tiene importantes ventajas funcionales y de seguridad en comparación con el lado del servidor puro o el flujo del lado del cliente puro.

El archivo Léame continúa describiendo la mecánica del flujo en sí, y termina con:

  

Este flujo es inmune a los ataques de repetición y no transmite información útil a un hombre en el medio.

No he podido encontrar ninguna explicación en la web sobre por qué esto es así, o cómo es superior a la autenticación OAuth 2.0 puramente del lado del servidor. La mayoría del material parece hablar solo de la mecánica de varias estrategias de OAuth.

Más específicamente, lo que no entiendo es esto: si es la misma información que fluye entre el cliente / servidor / proveedor de autenticación o simplemente el servidor / proveedor de autenticación, ¿tampoco es la estrategia tan susceptible a los ataques?

    
pregunta JonoB 28.07.2016 - 01:25
fuente

1 respuesta

3

Entonces, como ha descrito, una "Autenticación híbrida" es una solución intermedia entre la autenticación del lado del servidor y la del lado del cliente. Eso significa que todas las tareas involucradas para completar una autenticación necesitarán tanto el servidor como el cliente.

Así es como ocurre una autenticación del lado del servidor:

  • haz clic en el botón de inicio de sesión
  • obtienes el diálogo de consentimiento solicitando tu permiso
  • tienes que especificar un (redireccionar URI)
  • obtienes 2 cosas:

    1- ser redirigido a la redirección de URI

    2- obtener un código adjunto al URI de redirección (token de ID de usuario)

  • usted intercambia el (Token de ID de usuario < - > Token de acceso, Token de actualización) desde el servidor de autorización de Google # NO SECURE

Así es como se produce un flujo de código de una sola vez:

  • hace clic en el botón Iniciar sesión (se crea una variable de estado en el fondo)
  • obtienes el diálogo de consentimiento solicitando tu permiso
  • tienes que especificar un (redireccionar URI)
  • obtienes 2 cosas:

    1- ser redirigido a la redirección de URI (#State Variable se redirige de nuevo contigo)

    2- obtener un código adjunto al URI de redirección (token de ID de usuario)

  • intercambias ese código con tu servidor #VERY SECURE (Usted entrega el código + variable de estado, y el servidor compara esa variable de estado con la que ya tiene) #NO CSRF

  • el servidor intercambia (token de ID de usuario < - > token de acceso, token de actualización) desde el servidor de autorización de Google

Entonces, este intercambio aquí es inmune a los dos ataques de repetición y no proporciona un MITM con información útil, porque incluso si el atacante interceptó algún paquete, todavía tendrá que obtener esa variable de estado y procesar el código adjunto a través de servidor. Al contrario de la implementación del lado del servidor, donde todo lo que debe hacer el atacante es enviar el código a Google a cambio del token de acceso y el token de actualización.

Aquí también hay una imagen para poner las cosas en perspectiva, espero que la diferencia sea más clara ahora.

    
respondido por el Ahmed Salah El Din 12.01.2018 - 17:14
fuente

Lea otras preguntas en las etiquetas