OAuth 2.0: Beneficios y casos de uso: ¿por qué?

273

¿Alguien podría explicar qué tiene de bueno OAuth2 y por qué deberíamos implementarlo? Pregunto porque estoy un poco confundido al respecto; estos son mis pensamientos actuales:

Las solicitudes de OAuth1 (más precisamente HMAC) parecen lógicas, fáciles de entender, fáciles de desarrollar y realmente, realmente seguras.

OAuth2, en cambio, trae solicitudes de autorización, tokens de acceso y tokens de actualización, y debe realizar 3 solicitudes al comienzo de una sesión para obtener los datos que busca. E incluso entonces, una de sus solicitudes eventualmente terminará fallando cuando caduque el token.

Y para obtener otro token de acceso, usa un token de actualización que se pasó al mismo tiempo que el token de acceso. ¿Eso hace que el token de acceso sea inútil desde el punto de vista de la seguridad?

Además, como ha demostrado / r / netsec recientemente, SSL no es del todo seguro, por lo que el impulso de poner todo en TLS / SSL en lugar de un HMAC seguro me confunde.

OAuth argumenta que no se trata de un 100% de seguridad, sino de publicarlo y terminarlo. Eso no suena exactamente prometedor desde el punto de vista de un proveedor. Puedo ver lo que el borrador está tratando de lograr cuando menciona los 6 flujos diferentes, pero simplemente no encaja en mi cabeza.

Creo que podría ser más mi lucha por comprender sus beneficios y su razonamiento que el hecho de que realmente no me guste, por lo que esto puede ser un ataque un poco injustificado, y lo siento si esto podría parecer una perorata.

1
343

Antecedentes: escribí pilas de cliente y servidor para OAuth 1.0ay 2.0.

Tanto OAuth 1.0ay 2.0 admiten la autenticación de dos patas , donde un servidor tiene asegurada la identidad de un usuario, y la autenticación de tres patas , donde un proveedor de contenido asegura la identidad del usuario a un servidor. La autenticación de tres patas es donde entran en juego las solicitudes de autorización y los tokens de acceso, y es importante tener en cuenta que OAuth 1 también los tiene.

El complejo: autenticación de tres patas

Un punto principal de las especificaciones de OAuth es que un proveedor de contenido (por ejemplo, Facebook, Twitter, etc.) le asegure a un servidor (por ejemplo, una aplicación web que desea hablar con el proveedor de contenido en nombre del cliente) que el cliente tiene alguna identidad. . Lo que ofrece la autenticación de tres patas es la capacidad de hacerlo sin que el cliente o el servidor necesiten conocer los detalles de esa identidad (por ejemplo, nombre de usuario y contraseña).

Sin (?) Profundizar demasiado en los detalles de OAuth:

  1. El cliente envía una solicitud de autorización al servidor, que valida que el cliente es un cliente legítimo de su servicio.
  2. El servidor redirige al cliente al proveedor de contenido para solicitar acceso a sus recursos.
  3. El proveedor de contenido valida la identidad del usuario y, a menudo, solicita su permiso para acceder a los recursos.
  4. El proveedor de contenido redirige al cliente de vuelta al servidor, notificándole si ha tenido éxito o si ha fallado. Esta solicitud incluye un código de autorización en caso de éxito.
  5. El servidor realiza una solicitud fuera de banda al proveedor de contenido e intercambia el código de autorización por un token de acceso.

El servidor ahora puede realizar solicitudes al proveedor de contenido en nombre del usuario pasando el token de acceso.

Cada intercambio (cliente-> servidor, servidor-> proveedor de contenido) incluye la validación de un secreto compartido, pero dado que OAuth 1 puede ejecutarse a través de una conexión no cifrada, cada validación no puede pasar el secreto a través del cable.

Eso se hace, como ha notado, con HMAC. El cliente utiliza el secreto que comparte con el servidor para firmar los argumentos de su solicitud de autorización. El servidor toma los argumentos, los firma él mismo con la clave del cliente y puede ver si es un cliente legítimo (en el paso 1 anterior).

Esta firma requiere que tanto el cliente como el servidor estén de acuerdo en el orden de los argumentos (por lo que están firmando exactamente la misma cadena), y una de las principales quejas sobre OAuth 1 es que requiere que tanto el servidor como los clientes clasifiquen y firmar de forma idéntica. Este es un código complicado y es correcto o lo obtienes 401 Unauthorizedcon poca ayuda. Esto aumenta la barrera para escribirle a un cliente.

Al requerir que la solicitud de autorización se ejecute sobre SSL, OAuth 2.0 elimina la necesidad de ordenar y firmar los argumentos por completo. El cliente pasa su secreto al servidor, que lo valida directamente.

Los mismos requisitos están presentes en la conexión servidor-> proveedor de contenido, y dado que eso es SSL, elimina una barrera para escribir un servidor que accede a los servicios OAuth.

Eso facilita mucho las cosas en los pasos 1, 2 y 5 anteriores.

Entonces, en este punto, nuestro servidor tiene un token de acceso permanente que es un nombre de usuario / contraseña equivalente para el usuario. Puede realizar solicitudes al proveedor de contenido en nombre del usuario pasando ese token de acceso como parte de la solicitud (como un argumento de consulta, encabezado HTTP o datos de formulario POST).

Si se accede al servicio de contenido solo a través de SSL, hemos terminado. Si está disponible a través de HTTP simple, nos gustaría proteger ese token de acceso permanente de alguna manera. Cualquiera que olfatee la conexión podrá acceder al contenido del usuario para siempre.

La forma en que se resuelve en OAuth 2 es con un token de actualización . El token de actualización se convierte en el equivalente de contraseña permanente y solo se transmite a través de SSL . Cuando el servidor necesita acceso al servicio de contenido, intercambia el token de actualización por un token de acceso de corta duración. De esa manera, todos los accesos HTTP rastreables se realizan con un token que caducará. Google está usando un vencimiento de 5 minutos en sus API de OAuth 2.

Entonces, además de los tokens de actualización, OAuth 2 simplifica todas las comunicaciones entre el cliente, el servidor y el proveedor de contenido. Y los tokens de actualización solo existen para brindar seguridad cuando se accede al contenido sin cifrar.

Autenticación de dos patas

A veces, sin embargo, un servidor solo necesita controlar el acceso a su propio contenido. La autenticación de dos vías permite al cliente autenticar al usuario directamente con el servidor.

OAuth 2 estandariza algunas extensiones de OAuth 1 que se usaban ampliamente. El que mejor conozco fue introducido por Twitter como xAuth . Puede verlo en OAuth 2 como Credenciales de contraseña del propietario del recurso .

Básicamente, si puede confiarle al cliente las credenciales del usuario (nombre de usuario y contraseña), puede intercambiarlas directamente con el proveedor de contenido por un token de acceso. Esto hace que OAuth sea mucho más útil en aplicaciones móviles: con la autenticación de tres patas, debe incrustar una vista HTTP para manejar el proceso de autorización con el servidor de contenido.

Con OAuth 1, esto no formaba parte del estándar oficial y requería el mismo procedimiento de firma que todas las demás solicitudes.

Acabo de implementar el lado del servidor de OAuth 2 con las credenciales de contraseña del propietario del recurso y, desde la perspectiva del cliente, obtener el token de acceso se ha vuelto simple: solicite un token de acceso del servidor, pasando la identificación / secreto del cliente como un encabezado de autorización HTTP y el nombre de usuario / contraseña como datos del formulario.

Ventaja: simplicidad

Entonces, desde la perspectiva de un implementador, las principales ventajas que veo en OAuth 2 se encuentran en una complejidad reducida. No requiere el procedimiento de firma de solicitud, que no es exactamente difícil, pero ciertamente es complicado. Reduce en gran medida el trabajo requerido para actuar como cliente de un servicio, que es donde (en el mundo móvil moderno) más desea minimizar el dolor. La complejidad reducida en el extremo servidor-> proveedor de contenido lo hace más escalable en el centro de datos.

Y codifica en el estándar algunas extensiones de OAuth 1.0a (como xAuth) que ahora se utilizan ampliamente.

5
  • 24
    En cuanto a la terminología: sería mejor si se apegara a los nombres oficiales de las partes afectadas (servidor de autorización, servidor de recursos, propietario del recurso) en lugar de utilizar nombres poco claros (cliente, servidor, usuario ...). 14/10/2016 a las 9:21
  • Hola Peter, ¿puedes cambiar tu publicación con el servidor de autorización, el servidor de recursos, el propietario del recurso ... nombre del cliente, servidor, usuario ... como dice Aydin K.? Ayuda principalmente a los principiantes. Gracias. 10/11/2017 a las 7:29
  • @Aydin K puede comentar sobre la comparación de servidor de autorización, servidor de recursos, nombre del propietario del recurso del cliente, servidor, usuario. Porque también soy nuevo en Aouth. 10/11/2017 a las 7:35
  • 4
    Si alguien no entiende oauth. Explicar oauth utilizando términos de oauth en lugar de un lenguaje sencillo no parece productivo.
    Jay
    6/06/20 a las 6:33
  • ¿Es posible y tiene sentido introducir OAuth sin cambiar el código de la aplicación? 4 de enero a las 16:02
8

Primero, como se indica claramente en la autenticación OAuth

OAuth 2.0 no es un protocolo de autenticación.

La autenticación en el contexto de un usuario que accede a una aplicación le dice a una aplicación quién es el usuario actual y si está presente o no. Un protocolo de autenticación completo probablemente también le dirá una serie de atributos sobre este usuario, como un identificador único, una dirección de correo electrónico y cómo llamarlos cuando la aplicación diga "Buenos días".

Sin embargo, OAuth no le dice a la aplicación nada de eso. OAuth no dice absolutamente nada sobre el usuario, ni dice cómo el usuario demostró su presencia o incluso si todavía está allí. En lo que respecta a un cliente de OAuth, solicitó un token, obtuvo un token y, finalmente, usó ese token para acceder a alguna API. No sabe nada sobre quién autorizó la aplicación o si había un usuario allí.

Existe un estándar para la autenticación de usuarios mediante OAuth: OpenID Connect, compatible con OAuth2.

El token de ID de OpenID Connect es un token web JSON (JWT) firmado que se entrega a la aplicación cliente junto con el token de acceso OAuth normal. El token de identificación contiene un conjunto de afirmaciones sobre la sesión de autenticación, incluido un identificador para el usuario (sub), el identificador del proveedor de identidad que emitió el token (iss) y el identificador del cliente para el que se creó este token ( aud).

En Go, puede ver coreos / dex, un proveedor OpenID Connect Identity (OIDC) y OAuth 2.0 con conector enchufable.

Respuesta de esta publicación vonc

1
  • 2
    Entonces, si estuviera creando una aplicación en la que no hubiera clientes adicionales además del suyo, ¿sería aconsejable implementar OAuth? ¿O sería mejor ceñirse a la autenticación básica HTTP directa, evitando por completo OAuth? 18 de mayo de 2020 a las 0:55
6

Respondería esta pregunta de manera ligeramente diferente, y seré muy preciso y breve, principalmente porque @Peter T lo respondió todo.

La principal ganancia que veo de este estándar es respetar dos principios:

  1. Separación de intereses.
  2. Desacoplamiento de la autenticación de la aplicación web, que generalmente sirve a las empresas.

Al hacerlo,

  1. Puede implementar una alternativa al inicio de sesión único: si tiene varias aplicaciones que confían en un STS. Lo que quiero decir, un nombre de usuario para todas las aplicaciones.
  2. Puede habilitar su aplicación web (El cliente) para acceder a los recursos que pertenecen al usuario y no pertenecen a la aplicación web (El cliente).
  3. Puede encomendar el proceso de autenticación a un tercero en el que confíe y no preocuparse nunca por la validación de la autenticidad del usuario.