OAuth 2 vs OpenID Connect para asegurar la API

Navega tus respuestas
34

Estoy desarrollando una API web que respaldará varias aplicaciones: un sitio web, una (s) aplicación (es) móvil (es) complementaria (s) y posiblemente varias aplicaciones de terceros. Se espera que todas las aplicaciones obtengan un token de acceso del servidor de autenticación y luego lo ingresen a la API. El usuario ingresará sus credenciales ya sea en la interfaz web del servidor de autenticación (para aplicaciones de terceros) o directamente en el sitio web o la aplicación (para "de confianza" aplicaciones). No se espera que las propias aplicaciones cliente requieran la identidad del usuario.

Comencé a implementarlo a través de OAuth 2 y coincide exactamente con mis casos de uso. Pero más tarde encontré varias discusiones en la red que me hicieron pensar si mi escenario realmente requiere OpenID Connect, y ahora, después de unas pocas miles de palabras leídas, todavía no puedo gruñir cuál es la mejor para mi caso .

(Por ejemplo, GitHub, que coincide aproximadamente con mis casos de uso, utiliza OAuth 2)

Me gustaría escuchar algunas pautas sobre cómo elegir si la API de una requiere OAuth 2 o OpenID Connect.

Actualizar

Lo que me confunde es lo siguiente: hay un punto válido para no usar OAuth para autenticación . Pero considere este caso (suponga que hay una regla empresarial simple: cada usuario puede ver solo sus propios documentos):

  • la aplicación va al servidor de autenticación para el token
  • el usuario autoriza la aplicación, por lo que se otorga el token
  • la aplicación va a la API con el token para datos
  • api devuelve los documentos para el usuario que autorizó el token (de modo que de alguna manera el token se puede rastrear hasta el usuario)

¿Se trata de un escenario de autenticación o de autorización?

PS. Soy consciente de esta pregunta , pero la mejor La respuesta no responde a mis dudas.

    
pregunta Serg Rogovtsev 26.07.2015 - 20:02
fuente

2 respuestas

18

Por lo que ha explicado, parece que OAuth 2.0 se adaptaría mejor a sus necesidades. OpenID Connect fue desarrollado para agregar autenticación segura a OAuth 2.0. Los grandes proveedores, es decir, Google, Facebook, Yahoo, etc. comenzaron a utilizar OAuth 2.0 como una forma de autenticar a los usuarios con servicios de "inicio de sesión" para que los usuarios pudieran usar sus credenciales para autenticarse en una variedad de servicios de terceros. El estándar OAuth 2.0 no puede satisfacer de forma segura este requisito debido a deficiencias dentro del protocolo. OpenID Connect resuelve estas deficiencias y permite a los proveedores usar OAuth 2.0 de manera segura como marco de autenticación. OAuth 2.0 se desarrolló originalmente como un marco de autorización que permite a un usuario otorgar a un servicio de terceros acceso a sus datos almacenados en el proveedor. El escenario que describiste parece exactamente para lo que se desarrolló OAuth 2.0. Si no planea ofrecer un mecanismo de "inicio de sesión con" use OAuth 2.0.

Si un usuario tendrá sus propias credenciales para los servicios de terceros y no utilizará las credenciales de sus proveedores para iniciar sesión en el servicio, no necesitará OpenID Connect.

Este fue el recurso más útil que encontré. Es una publicación del blog de uno de los diseñadores de OpenID Connect que aborda los diferentes usos de Facebook para OAuth 2.0.

    
respondido por el Justin Moore 30.07.2015 - 04:43
fuente
10

Primero que nada, como probablemente sepas, OpenID Connect es solo una capa de autenticación construida sobre OAuth2. Por lo tanto, independientemente de cuál elija, deberá implementar OAuth2 (como denominador común).

OAuth2 en sí mismo es un mecanismo de autorización (es decir, le permite verificar que un token es válido y tiene un conjunto específico de ámbitos otorgados). No proporciona autenticación fuera de la caja (no se puede decir de inmediato "quién" es el usuario).

Sin embargo, en muchos casos, es posible que esté buscando la autenticación tanto como . En este caso, necesita una capa sobre OAuth2 para proporcionar eso. Esto se hace con mayor frecuencia haciendo que el servidor de recursos exponga algún tipo de "¿Quién soy yo?" punto final que devuelve la identidad del usuario asociado con el token de acceso.

OpenID Connect hace eso y proporciona una forma estándar de obtener y representar la identidad del usuario (ese es el objeto devuelto por UserInfo punto final) como un conjunto de reclamaciones .

También permite que la aplicación cliente reciba la información del usuario junto con el token de acceso (que es el id_token devuelto por el punto final del token o incluido junto con el código de autorización como un token JWT firmado, dependiendo de su flujo), que guarda una solicitud HTTP.

OpenID Connect también proporciona un montón de otras cosas que IMO son de menor interés (registro dinámico, etc.).

Entonces, para responder a su pregunta sobre OAuth2 frente a OpenID Connect: si necesita autenticación para sus API, deberá implementarla sobre OAuth2. Puedes hacer algo personalizado o puedes implementar OpenID Connect. OpenID Connect es muy complejo si desea implementar la especificación completa, pero es relativamente fácil si solo desea implementar el MVP para autenticar a un usuario (implemente el punto final de información del usuario y use la representación estándar, y tal vez problema id_tokens).

Para obtener más información, consulte la especificación de OpenID Connect .

    
respondido por el Christophe L 30.07.2015 - 20:22
fuente

Lea otras preguntas en las etiquetas

Implicaciones de seguridad de rootear Android Cómo comenzar a escribir software criptográfico [cerrado]