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

oauth-2.0 (3)

¿Alguien podría explicar qué es lo bueno de OAuth2 y por qué debemos implementarlo? Lo pregunto porque estoy un poco confundido al respecto, aquí están 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 usted tiene que hacer 3 solicitudes al inicio de una sesión para obtener los datos que busca. E incluso entonces, una de sus solicitudes terminará fallando cuando el token caduque.

Y para obtener otro token de acceso, utiliza 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 un punto de vista de seguridad?

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

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

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

Antecedentes: He escrito pilas de cliente y servidor para OAuth 1.0ay 2.0.

Tanto OAuth 1.0a como 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 servidor está asegurado por un proveedor de contenido de la identidad del usuario. La autenticación de tres etapas 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: la autenticación de tres patas.

Un punto principal de las especificaciones de OAuth es que un proveedor de contenido (por ejemplo, Facebook, Twitter, etc.) 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:

El cliente envía una solicitud de autorización al servidor, lo que valida que el cliente sea un cliente legítimo de su servicio.
El servidor redirige al cliente al proveedor de contenido para solicitar acceso a sus recursos.
El proveedor de contenido valida la identidad del usuario y, a menudo, solicita su permiso para acceder a los recursos.
El proveedor de contenido redirige al cliente de nuevo al servidor, notificándolo de éxito o fracaso. Esta solicitud incluye un código de autorización en caso de éxito.
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 al pasar el token de acceso.

Cada intercambio (cliente-> servidor, servidor-> proveedor de contenido) incluye la validación de un secreto compartido, pero como OAuth 1 puede ejecutarse sobre una conexión no cifrada, cada validación no puede pasar el secreto por el cable.

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

Esta firma requiere que tanto el cliente como el servidor estén de acuerdo con el orden de los argumentos (para que firmen 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 incómodo y, o bien, está bien, o recibe 401 Unauthorized con poca ayuda. Esto aumenta la barrera para escribir 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 del servidor -> proveedor de contenido, y ya que es SSL que elimina una barrera para escribir un servidor que accede a los servicios de OAuth.

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

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 al pasar 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. Cualquier persona que rastree 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 la contraseña permanente equivalente, 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 sniffable se hacen con un token que caducará. Google está utilizando una caducidad de 5 minutos en sus API OAuth 2.

Entonces, aparte 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 proporcionar 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 patas permite al cliente autenticar al usuario directamente con el servidor.

OAuth 2 estandariza algunas extensiones de OAuth 1 que estaban en uso generalizado. El que mejor conozco fue introducido por Twitter como xAuth . Puede verlo en OAuth 2 como credenciales de contraseña del propietario del recurso .

Esencialmente, si puede confiar al cliente las credenciales del usuario (nombre de usuario y contraseña), pueden 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 integrar una vista HTTP para manejar el proceso de autorización con el servidor de contenido.

Con OAuth 1, esto no formaba parte de la norma 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 el ID / secreto del cliente como un encabezado de autorización HTTP y usuario de inicio de sesión / contraseña como datos de formulario.

Ventaja: Simplicidad

Entonces, desde la perspectiva de un implementador, las principales ventajas que veo en OAuth 2 son de complejidad reducida. No requiere el procedimiento de firma de solicitud, que no es exactamente difícil, pero sin duda es complicado. Reduce en gran medida el trabajo requerido para actuar como cliente de un servicio, que es donde (en el mundo moderno y móvil) más desea minimizar el dolor. La complejidad reducida en el servidor -> el extremo del 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 están en uso generalizado.

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 la aplicación quién es el usuario actual y si está presente o no. Un protocolo de autenticación completo probablemente también le indicará 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 dice "Buenos días".

Sin embargo, OAuth 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án allí. En lo que respecta a un cliente OAuth, solicitó un token, obtuvo un token y finalmente lo utilizó para acceder a algunas API. No sabe nada sobre quién autorizó la aplicación o si hubo un usuario allí.

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

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

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

Respuesta de este post vonc

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

El principal beneficio que veo en este estándar es respetar dos principios:

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

Al hacerlo,

Puede implementar una alternativa a Single SignOn: si tiene varias aplicaciones que confían en un STS. Lo que quiero decir, un nombre de usuario para todas las aplicaciones.
Puede habilitar su aplicación web (el cliente) para acceder a recursos que pertenecen al usuario y no pertenecen a la aplicación web (el cliente).
Puede ordenar el proceso de autenticación a un tercero de confianza, y nunca preocuparse por la validación de autenticidad del usuario.