¿Alguien podría explicar qué tiene de bueno OAuth2 y por qué deberíamos implementarlo? 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 muy 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 caduque el token.
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 han demostrado recientemente / r / netsec, SSL no es completamente seguro, por lo que el empuje para llevar todo a TLS / SSL en lugar de un HMAC seguro me confunde.
OAuth argumenta que no se trata del 100% de seguridad, sino de publicarlo y finalizarlo. 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 difícil para mí comprender sus beneficios y su razonamiento que no disgustarlo, por lo que esto puede ser un ataque injustificado, y lamento si esto puede parecer una queja.
Respuestas:
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 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 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 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 como OAuth 1 puede ejecutarse a través de una conexión no cifrada, cada validación no puede pasar el secreto por el cable.
Eso está hecho, como ya lo notó, 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 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 acuerden 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 forma idéntica. Este es un código incómodo y es correcto o se obtiene
401 Unauthorizedcon poca ayuda. Esto aumenta la barrera para escribir un cliente.Al requerir que la solicitud de autorización se ejecute a través de SSL, OAuth 2.0 elimina la necesidad de ordenar y firmar 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 dado 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.
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 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 detecte 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 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 sniffable se realizan con un token que caducará. Google está utilizando una caducidad de 5 minutos en sus API de 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
Sin embargo, a veces, 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 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 .
Esencialmente, si puede confiar en el 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 incrustar una vista HTTP para manejar el proceso de autorización con el servidor de contenido.
Con OAuth 1, esto no era 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 el ID / secreto del cliente como un encabezado de autorización HTTP y inicio de sesión / 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 están en una complejidad reducida. No requiere el procedimiento de firma de solicitud, lo cual 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 moderno y móvil) desea minimizar el dolor. La complejidad reducida en el servidor-> proveedor de contenido final 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 usan ampliamente.
fuente
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 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 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 alguna API. No sabe nada sobre quién autorizó la aplicación o si incluso hubo un usuario allí.
Existe un estándar para la autenticación de usuarios con 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 ID contiene un conjunto de reclamos sobre la sesión de autenticación, que incluye 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 ver coreos / dex, una identidad de conexión OpenID (OIDC) y un proveedor OAuth 2.0 con conector enchufable.
Respuesta de este post vonc
fuente
Contestaría esta pregunta de forma 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:
Al hacerlo,
fuente