¿Por qué el servidor cliente no puede hablar directamente con un proveedor de identidad como Facebook en OAauth 2.0

Question

¿Por qué el servidor cliente no puede hablar directamente con un proveedor de identidad como Facebook en OAauth 2.0

#1 de Christian Strempfer (2 votos)

2

OAuth 2.0 utilizado por Google para la autenticación tiene sentido dado que tanto el servidor como el cliente confían en Google pero no en los demás.

Según tengo entendido, el código de autorización se devuelve al servidor (en el flujo del lado del servidor) como un parámetro de URL. Para evitar problemas de seguridad como el agente confundido, el código de autorización se usa una sola vez y el servidor puede usar el código de autorización para obtener un token de acceso y un token de actualización.

Mi pregunta es ¿por qué no se puede simplificar este proceso si Google (una entidad de confianza) envía directamente el token de acceso al servidor (y no a través del cliente)? Esto eliminaría la necesidad de un código de autorización. Google puede estar seguro de que está enviando el token de acceso al lugar correcto porque el cliente habría registrado el redirect_uri con Google de antemano. Parece ser un patrón general que estos protocolos hacen que el proveedor de identidad solo envíe cosas al servidor a través del cliente.

authentication oauth oauth2 url-redirection

pregunta curiousgeorge 02.06.2018 - 06:44

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication oauth oauth2 url-redirection

¿SSL aún es seguro si la configuración de SSL en IIS está configurada para ignorar o aceptar solo? ¿Es seguro mantener una imagen del cheque aprobado?

score 2 · Answer 1

Aunque sería posible, el proceso sería más complejo y, por lo tanto, una implementación defectuosa sería más probable.

Por ejemplo, podría funcionar así:

redirigir al punto final de autenticación de OAuth, incluir un identificador de sesión
el usuario inicia sesión
El proveedor OAuth envía el token de autenticación y el identificador de sesión al servidor solicitante
la sesión del usuario está vinculada con el token de autenticación
el usuario se redirige a REDIRECT_URI

El identificador de sesión es necesario, porque de lo contrario, un atacante con una buena sincronización podría tomar el token de autenticación. Como puede ver, el identificador de sesión está reemplazando el token de autenticación para identificar al cliente en este ejemplo, lo que significa que enviar el token de servidor a servidor es solo un paso adicional.

el cliente habría registrado previamente el redirect_uri con Google

El registro haría que el sistema fuera menos flexible, ya que actualmente solo el servicio de llamada debe decidir en qué proveedor de OAuth confiar. Mediante el uso de registros, la relación debe establecerse en dos lados.