Autorizar la comunicación transitiva entre aplicaciones en nombre del usuario

4

Estoy tratando de envolver mi cabeza para seguir una pregunta de seguridad web por un tiempo. Digamos que tenemos un sistema configurado como se muestra en la siguiente imagen.

Hayunaaplicaciónprincipalconlaqueelusuariointeractúalamayorpartedeltiempoatravésdeunextremodelantero.Apartedelaaplicaciónprincipal,haymúltiplesaplicacionesmáspequeñas.Estasaplicacionestambiéntieneninterfacesconlasqueelusuariopuedeinteractuar.Comonoqueremostenerunabasededatosdeusuariosdiferenteparacadaunadeestasaplicaciones,decidimosusaroAuth2paralaautenticación.

Laaplicaciónprincipalpuedeinteractuarconestosotrossistemasyviceversa.Lamayoríadelasvecesesenelcontextodeunainteraccióndeusuario.

Lasolicituddelaaplicaciónprincipalaotraaplicacióndebeser(1)autorizaday(2)nosgustaríasaberen"otra aplicación" en nombre de qué usuario se inició la llamada (no como "Aplicación principal", pero "Usuario").

Es realmente tentador enviar el token oAuth del usuario desde la aplicación principal a otra aplicación. Pero esto podría tener serias implicaciones de seguridad, ya que "otra aplicación" ahora tendría todos los derechos del usuario para moderar la aplicación principal ( enlace ).

Esto podría no ser tan malo, ya que nosotros mismos administramos estos servicios, pero ciertamente no es el enfoque correcto en caso de que estemos tratando con aplicaciones de terceros.

En resumen, mi pregunta es: si el usuario inicia una solicitud en una aplicación, que a su vez tiene que llamar a otra aplicación para completar la solicitud, ¿cómo podemos:

  • Autorice esta segunda llamada de la aplicación a otra aplicación (dado que el usuario está autorizado y tenemos un sistema central de autenticación de oAuth)
  • Y aún así, de alguna manera, sé en nombre de qué usuario se inició la llamada.

Idealmente, el extremo receptor de la llamada ni siquiera sabría que la llamada fue iniciada por la otra aplicación (solo pensaría que es una llamada directa de un usuario). Solo usaría los interceptores de seguridad de oAuth ya instalados.

EDIT:

Un pensamiento que tengo es agregar algún tipo de concesión de autorización adicional al servidor de Autorización que toma como entrada:

  • credenciales de propietario de recursos válidas
  • un token válido del usuario que inicia la solicitud
  • el ID del servidor de recursos al que accederemos

El servidor de autorización sabe, dadas las credenciales del propietario del recurso que solicita:

  • qué ID de servidor de recursos están permitidos
  • qué permisos se pueden retener del token original

El servidor de autorización:

  • valida las credenciales del servidor de recursos que solicitan
  • valida el token de usuario
  • valida si el servidor de recursos solicitante puede solicitar un token para el servidor de recursos solicitado
  • retiene la intersección del permiso de usuario en los tokens de usuario y los permisos de usuario permitidos para el servidor de recursos solicitante

El resultado es un token de corta duración (no actualizable)

  • en nombre del usuario solicitante
  • solo teniendo el id del servidor de recursos al que accederemos como audiencia
  • tener un subconjunto de permisos del token original.
pregunta badoit 03.06.2018 - 09:39
fuente

1 respuesta

0

Como (esperaba) no podía ser la primera persona en estar en esta situación, he logrado encontrar varias referencias en la web que hablan sobre los tipos de becas de "delegación":

Esto es exactamente de lo que estaba hablando en mi idea. Espero que esto pueda ayudar a otras personas en la misma situación.

    
respondido por el badoit 08.06.2018 - 21:35
fuente

Lea otras preguntas en las etiquetas