OAuth 2.0: Beneficios y casos de uso: ¿por qué?
¿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 OAuth1 (más precisamente HMAC) parecen lógicas, fáciles de entender, fáciles de desarrollar y 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 terminará fallando cuando el token caduque.
Y para obtener otro token de acceso, se 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 el punto de vista de la seguridad?
Además, como /r/netsec ha demostrado recientemente, SSL no es del todo seguro, por lo que la presión para colocar todo en TLS/SSL en lugar de un HMAC seguro me confunde.
OAuth argumenta que no se trata de 100% de seguridad, sino de publicarlo y terminarlo. Esto no suena precisamente 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 deberse más a mi lucha por comprender sus beneficios y su razonamiento que a que realmente no me guste, por lo que esto puede ser un ataque un poco injustificado, y lo siento si esto puede parecer una perorata.
Antecedentes: he escrito pilas de clientes y servidores para OAuth 1.0a y 2.0.
Tanto OAuth 1.0a como 2.0 admiten la autenticación de dos vías , donde un servidor tiene garantizada la identidad de un usuario, y la autenticación de tres vías , donde un proveedor de contenido garantiza a un servidor la identidad del usuario. 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.) 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, que valida que el cliente es un cliente legítimo de su servicio.
- El servidor redirige al cliente al proveedor de contenidos 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 al servidor y le notifica el éxito o el 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 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 por cable.
Esto se hace, como habrás 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 firman exactamente la misma cadena), y una de las principales quejas sobre OAuth 1 es que requiere que tanto el servidor como los clientes ordenen y firmar de manera idéntica. Este es un código complicado y o es correcto o se obtiene 401 Unauthorizedcon poca ayuda. Esto aumenta la barrera para escribirle a un cliente.
Al requerir que la solicitud de autorización se ejecute a través de SSL, OAuth 2.0 elimina por completo la necesidad de ordenar y firmar argumentos. 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 es SSL, se elimina una barrera para escribir un servidor que acceda 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 equivalente de nombre de usuario/contraseña 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 argumento de consulta, encabezado HTTP o datos de formulario POST).
Si se accede al servicio de contenido sólo 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 husmee la conexión podrá obtener acceso 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 la 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 utiliza una caducidad de 5 minutos en sus API de OAuth 2.
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 sólo 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 presentado 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 incorporar una vista HTTP para poder 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 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 del usuario como datos del formulario.
Ventaja: simplicidad
Entonces, desde la perspectiva de un implementador, las principales ventajas que veo en OAuth 2 son la complejidad reducida. No requiere el procedimiento de firma de solicitud, lo cual no es exactamente difícil pero sí complicado. Reduce en gran medida el trabajo necesario para actuar como cliente de un servicio, que es donde (en el mundo móvil moderno) más se desea minimizar el dolor. La complejidad reducida en el extremo del 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.
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 diga "Buenos días".
Sin embargo, OAuth no le dice nada de eso a la aplicación. 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 OAuth, solicitó un token, obtuvo un token y finalmente lo usó para acceder a alguna API. No sabe nada sobre quién autorizó la aplicación o si había algún usuario allí.
Existe un estándar para la autenticación de usuarios mediante OAuth: OpenID Connect, compatible con OAuth2.
El token de identificación de OpenID Connect es un token web JSON (JWT) firmado que se proporciona 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 cual se creó este token ( aud).
En Go, puede ver coreos/dex, un proveedor OpenID Connect Identity (OIDC) y OAuth 2.0 con conector conectable.
Respuesta de esta publicación vonc
Respondería esta pregunta de manera ligeramente diferente y seré muy preciso y breve, principalmente porque @Peter T lo respondió todo.
El principal beneficio que veo de esta norma es respetar dos principios:
- Separación de intereses.
- Desacoplar la autorización de la aplicación web, que suele servir a las empresas.
Al hacerlo,
- Puede implementar una alternativa al inicio de sesión único: si tiene varias aplicaciones que confían en un STS. Lo que quiero decir es un conjunto de credenciales para todas las aplicaciones.
- Puede habilitar su aplicación web (El cliente) para acceder a recursos que le pertenecen y no pertenecen a la aplicación web (El cliente).
- Puede encargar el proceso de autorización a un tercero en el que confíe y no preocuparse nunca por la validación de la autenticidad del usuario.
