Usando múltiples servicios de identidad oAuth simultáneamente

Question

Usando múltiples servicios de identidad oAuth simultáneamente

#1 de GnP (1 votos)
#2 de Pascal (1 votos)

7

Esta pregunta es algo acedémica por naturaleza. Al informarme sobre el tema de Seguridad a través de los tokens de portador para un servicio de fondo en el que estoy trabajando, y específicamente sobre oAuth2, surgieron algunas preguntas en mi mente:

Si tuviera que externalizar el proveedor de identidad / servicio de autorización, creará una dependencia en ese proveedor de servicio. ¿Qué tan difícil sería mudarse a un nuevo proveedor de servicios oAuth2?
¿Qué sucede si el proveedor de servicios "falla" (desaparece de Internet o tiene sus sistemas comprometidos o cambia sus políticas de una manera que es incompatible con sus requisitos, etc.)?

Como una forma de reducir la dependencia, se me ocurrió que podría ser capaz de configurar el servidor de recursos para verificar que cada solicitud tenga dos tokens, de dos proveedores de servicios diferentes, por ejemplo, SP-A y SP-B.

Para hacer que los usuarios de sus [clientes] tengan que "registrarse" tanto en SP-A como en SP-B. Eso implicaría que durante el proceso de registro, los detalles de los usuarios se enviarían y los registros se crearían tanto en SP-A como en SP-B.

Los desarrolladores clientes se verán afectados porque deben desarrollar sus aplicaciones para registrar usuarios con dos proveedores de OAuth y deben obtener códigos de autorización de dos proveedores. Para los usuarios finales, el impacto puede minimizarse, pero si un cliente quisiera usar los IdP de OpenID existentes de los usuarios para efectuar el registro inicial y la autenticación de inicio de sesión, el usuario tendría que autorizar DOS accesos a sus datos.

El único beneficio inmediato sería que luego podría establecer una marca global en el back-end para cada SP-A y SP-B, para ignorar / omitir a ese proveedor, en caso de que lo necesite.

También puede usar políticas diferentes, por ejemplo, requiere un token válido de todos los proveedores de oAuth, o de al menos un proveedor de oAuth, etc., según sus requisitos.

Por supuesto, uno siempre tendría que revisar las credenciales de un Proveedor de Autorización, realizar un seguimiento de su historial, etc. e intentar evaluar los riesgos.

oauth identity-management

pregunta Johan 27.01.2015 - 17:17

fuente

2 respuestas

Lea otras preguntas en las etiquetas oauth identity-management

Modificar código C con vulnerabilidad de desbordamiento de búfer para omitir código ¿Hay alguna razón para usar AesManaged sobre DPAPI en este escenario?

score 1 · Answer 1

No estoy seguro de lo que quieres decir. Aquí están mis dos mejores conjeturas:

OAuth para autorización

OAuth le permite a un tercero (usted) acceder a los recursos protegidos de un usuario desde un servidor de recursos (probablemente una API) después de obtener la autorización a través de un servidor de autorización (el proveedor de OAuth).

El proveedor de OAuth es probablemente la misma organización que ejecuta el servidor de recursos. Si la organización desaparece de Internet, realmente no tiene sentido tener un proveedor diferente para obtener la autorización de un recurso inexistente.
OAuth para la autenticación

También existe la posibilidad de que te refieras a usar un servicio de identidad de terceros para autenticar a los usuarios en tu sitio.

Si ese es el caso, no necesita vincularse a un servicio en particular, solo use OpenID Connect y deje que sus usuarios elijan el proveedor que prefieran.

Puede ofrecer botones de acceso rápido para los proveedores más comunes, pero no depende de ellos.

Ah, las alegrías de los servicios federados :-)

Hazme saber si entendí mal la pregunta por completo.

score 1 · Answer 2

Los desarrolladores clientes se verán afectados porque deben desarrollar sus aplicaciones para registrar usuarios con dos proveedores de OAuth y deben obtener códigos de autorización de dos proveedores. [...]

Registrar usuarios con varios proveedores de oAuth y obtener códigos de autorización de varios proveedores de oAuth es, como ya dijo GnP, un problema en teoría, ya que Open ID Connect le brinda un protocolo estándar e incluso un método de descubrimiento estándar para los puntos finales api. Usted escribe el código para obtener un código de autorización y lo cambia por un ID y un token de acceso una vez, y lo ejecuta contra todos los proveedores compatibles (aunque su millaje puede variar, implementé exitosamente mi código contra las implementaciones de Open ID Connect de Google y Microsoft Azure, pero cuando probé Yahoo, Yahoo no se comportó de acuerdo con las especificaciones y no dio ninguna razón por la que no lo hizo ...

Ignorar esa advertencia, admitir múltiples proveedores de identidad en lugar de solo uno es básicamente la diferencia entre usar una relación 1: 1 y una relación 1: n en su base de datos de usuario, por ejemplo. en lugar de adjuntar un único identificador de asunto de Open ID Connect a cada una de sus entidades de usuario, diseñe su base de datos para permitir la conexión de un número arbitrario de ellos, y cada vez que quiera apoyar a un nuevo proveedor de Identidad, básicamente todo lo que tiene que hacer (Si se comporta de acuerdo con las especificaciones) es darle a su aplicación el nombre de dominio donde reside el documento de descubrimiento de IDP.

pero si un cliente quisiera usar los IdP de OpenID existentes de los usuarios para efectuar el registro inicial y la autenticación de inicio de sesión, el usuario tendría que autorizar DOS accesos a sus datos.

Considero que la autorización es el problema más difícil de resolver, pero no por la razón que me das, y solo la tengo porque tengo una base de usuarios preexistente con un conjunto bien definido de derechos de acceso. Mi problema es este: Básicamente, cada proveedor de Open ID le brinda una cadena aleatoria que identifica a un usuario, pero ¿cómo se relacionan estas cadenas con sus entidades de usuario (y, por lo tanto, con su autorización)? Las cadenas de asunto que obtiene de un IDP parecen completamente aleatorias y no las puede conocer de antemano, por lo que si tiene una base de usuarios conocida para la cual ha definido varios derechos de acceso, ¿cómo puede hacer coincidir una identificación que no puede predecir? una entidad de usuario dada en su marco de autorización?

(La forma en que resolví esto es usar la dirección de correo electrónico que el IdP me da como parte del token de identificación como un identificador único y conocido para vincular el identificador del sujeto de un IdP a mis entidades de usuario la primera vez que veo una nueva el usuario se autentica, pero para que funcione, debe confiar en que el IdP verifica las direcciones de correo electrónico correctamente, una apuesta que no estaría dispuesta a aceptar por cada IdP que haya allí.

Entonces, sí, permitir que múltiples proveedores de identidad genere algún trabajo adicional, pero es principalmente en la configuración de diferentes modelos de confianza para diferentes IdP. En mi caso, confío en un identificador de identificación de mi IdP primario de forma implícita, y solo acepto un pequeño conjunto de otros IdPs, en los que no confío para que me proporcionen información verificada más allá del identificador de sujeto del identificador de identidad, por lo que para estos , Necesito una segunda solución al problema de coincidencia / autorización que presenté anteriormente.

Si no trabajaste con una base de usuarios preexistente, la forma de resolver el problema de coincidencia sería permitir que un usuario fusione sus múltiples identidades vinculándolas todas a la misma cuenta de usuario. Puede hacerlo si se autentica con una cuenta de usuario y luego, mientras está autenticado, dígale que se autentique con sus otros proveedores de Identidad. Su aplicación podría vincular todas estas identidades juntas como pertenecientes a la misma persona / entidad de usuario en su base de datos.