OIDC Flow para SPA y RESTful API

Navega tus respuestas
10

Estoy creando una Aplicación de una sola página (SPA) y una RESTful API . La API necesita seguridad: ciertos usuarios solo pueden hacer llamadas a ciertos puntos finales. Tengo un proveedor de identidad externo (IdP (Okta)) con el que quiero que el usuario se autentique utilizando el protocolo OpenId Connect . Estoy tratando de aclarar los pasos correctos para la autenticación y autorización del SPA a la API RESTful. Los dos flujos que he estado observando son el flujo del código de Autorización y el flujo Implícito.

Si tuviera que ir con Flujo implícito , los pasos serían:

  1. El usuario visita el SPA, que lo redirige al IdP para iniciar sesión.
  2. Una vez que el usuario inicia sesión, el IdP lo devuelve al SPA con un token de acceso y un token de ID.
  3. (Este es el paso del que no estoy seguro) Cada vez que el SPA realiza una solicitud a la API RESTful, pasa el token de acceso y el token de ID junto con la solicitud, que la API RESTful valida y luego comprueba que el usuario tiene autoridad para acceder al punto final en particular. Si lo hace, devuelve el resultado, de lo contrario, el usuario no está autorizado.

Si tuviera que ir con el flujo de código de autorización , los pasos serían:

  1. Igual que el paso 1 anterior.
  2. Una vez que el usuario inicia sesión, el IdP lo devuelve al SPA con un código de autorización.
  3. (De nuevo, el paso no estoy seguro es correcto) Cada vez que el SPA realiza una solicitud a la API RESTful, pasa el código de autorización junto con la solicitud, que la API RESTful luego intercambia (junto con un secreto del cliente) con el IdP para un token de acceso y un token de ID. Los utiliza para comprobar si el usuario puede acceder a un punto final en particular. Si lo hace, devuelve el resultado, de lo contrario no están autorizados.

Creo que el flujo implícito es el que se usa en este escenario, pero ¿tengo los pasos correctos? Particularmente el paso 3, el envío de dos fichas en cada solicitud, no parece correcto. Pero creo que necesito ambos tokens para validar y determinar el usuario. Ayuda apreciada!

    
pregunta Steve 13.07.2016 - 06:54
fuente

1 respuesta

10

Aquí está la diferencia entre Flujo implícito y Flujo de código de autor:

Flujo implícito

  1. El usuario navega a SPA, que redirige al usuario a IdP para que inicie sesión.
  2. El usuario inicia sesión (y autoriza la aplicación, si es necesario).
  3. IdP devuelve al usuario a SPA con token de acceso y token de ID.
  4. El código JavaScript en SPA almacena el token de acceso y el token de ID en el localStorage del navegador y envía el Token de acceso al servidor REST API para cada solicitud que realiza (generalmente como un encabezado Authorization: Bearer <access token> ).
  5. Si es necesario, el servidor de API REST verifica la validez del token de acceso hablando con el IdP. (A menudo, firmar el token en el IdP y verificar que la firma será suficiente y que en realidad no es necesaria la comunicación).

Flujo de código de autorización

  1. El usuario navega a SPA, que redirige al usuario a IdP para que inicie sesión.
  2. El usuario inicia sesión (y autoriza la aplicación, si es necesario).
  3. IdP devuelve al usuario a SPA con código de autorización.
  4. El código JavaScript en SPA envía el Código de autorización a un punto final login en el servidor de API REST.
  5. El servidor de API REST envía una solicitud al servidor de IdP que contiene el Código de autorización (y generalmente también una ID de cliente y un secreto de cliente que identifican el servidor de API de REST para el servidor de IdP).
  6. El IdP valida el Código de autorización y envía el token de acceso y el token de ID al servidor API REST.
  7. El servidor de API REST almacena el token de acceso y el token de ID en su memoria, y envía su propio token de sesión al SPA.
  8. Para cada solicitud que el SPA realiza al servidor de API REST, incluye el token de sesión que le dio el servidor de API REST. Si el servidor de API REST necesita solicitar recursos de otro servidor, utiliza el token de acceso almacenado para realizar esa solicitud.

Desde aquí puede ver que el flujo de AuthCode es significativamente más complicado que el flujo implícito, pero con el beneficio de que el token de acceso nunca se almacena en el control del usuario.

Sin embargo, el punto principal de almacenar el token en este caso no es para su propia autenticación, sino para el caso en el que el servidor de API REST necesita hablar con otros servicios, como Google, Facebook, Twitter, etc.

Si solo está utilizando OpenID Connect para iniciar sesión en su propio servidor REST API, las credenciales nunca deben ser utilizadas por el propio servidor, la implementación de Implicit Flow es mucho más fácil y la implementación de AuthCode flow no lo hace. en realidad te gana algo.

    
respondido por el Moshe Katz 19.07.2016 - 22:21
fuente

Lea otras preguntas en las etiquetas

Divulgaciones responsables y ser demandado ¿Qué tan segura es la opción “confiar en esta computadora” para los sitios web?