Nuestro grupo de especialistas despúes de algunos días de trabajo y de juntar de información, hallamos la respuesta, nuestro deseo es que resulte útil para ti en tu plan.
Solución:
La siguiente respuesta solo se aplica a un flujo de autenticación de OpenID Connect con un IDP de terceros (como Google). No se aplica a una arquitectura en la que aloja su propio IDP.
(Hay algunas puertas de enlace API (por ejemplo, Tyk o Kong) que admiten OpenID Connect de fábrica).
Puede usar JWT (token de ID) para proteger sus API. Sin embargo, esto tiene una desventaja. Los JWT no se pueden revocar fácilmente.
No recomendaría esto. En su lugar, debe implementar un servidor de autorización OAuth2 que emita tokens de acceso para su API. (En este caso, tiene dos flujos OAuth2. Uno para la autenticación y otro para la autorización. El ID y el token de acceso del IDP se usan solo para la autenticación).
La siguiente imagen muestra una configuración donde la puerta de enlace API y el servidor de autenticación/autorización son dos servicios separados. (Como se mencionó anteriormente, la puerta de enlace API también puede realizar la autenticación/autorización).
Las llamadas de flujo de autenticación (Concesión de código de autorización) están marcadas en azul. Las llamadas de flujo de autorización (concesión implícita) están marcadas en verde.
1: Su aplicación web se carga desde el servidor de aplicaciones.
2a: el usuario hace clic en su botón de inicio de sesión, su aplicación web crea la URL de autorización y la abre. (Ver: Solicitud de Autorización)
2b: debido a que el usuario no se ha autenticado y no tiene una sesión válida con su servidor de autorización, la URL a la que quería acceder se almacena y su servidor de autorización responde con una redirección a su página de inicio de sesión.
3: La página de inicio de sesión se carga desde su servidor de autorización.
4a: El usuario hace clic en “Iniciar sesión con…”.
4b: su servidor de autorización crea la URL de autorización de IDP y responde con una redirección. (Ver: Solicitud de autenticación)
5a: La URL de autorización de IDP está abierta.
5b: Debido a que el usuario no se ha autenticado y no tiene una sesión válida con el IDP, la URL a la que quería acceder se almacena y el IDP responde con una redirección a su página de inicio de sesión.
6: La página de inicio de sesión se carga desde el IDP.
7a: El usuario completa sus credenciales y hace clic en el botón de inicio de sesión.
7b: el IDP verifica las credenciales, crea una nueva sesión y responde con una redirección a la URL almacenada.
8a: La URL de autorización de IDP se abre de nuevo.
(Los pasos de aprobación se ignoran aquí por simplicidad).
8b: el IDP crea una autorización y responde con una redirección a la URL de devolución de llamada de su servidor de autorización. (Ver: Respuesta de autenticación)
9a: se abre la URL de devolución de llamada.
9b: Su servidor de autorización extrae el código de autorización de la URL de devolución de llamada.
10a: Su servidor de autorización llama al extremo del token del IDP, obtiene una identificación y un token de acceso y valida los datos en el token de identificación. (Ver: Solicitud de Token)
(10b: su servidor de autorización llama al extremo de información de usuario del IDP si algunas notificaciones necesarias no están disponibles en el token de ID).
11a/b: Su servidor de autorización consulta/crea el usuario en su servicio/BD, crea una nueva sesión y responde con una redirección a la URL almacenada.
12a: La URL de autorización se abre de nuevo.
(Los pasos de aprobación se ignoran aquí por simplicidad).
12b/+13a/b: su servidor de autorización crea/obtiene la autorización (crea un token de acceso) y responde con una redirección a la URL de devolución de llamada de su aplicación web. (Ver: Respuesta de token de acceso)
14a: Se abre la URL de devolución de llamada.
14b: su aplicación web extrae el token de acceso de la URL de devolución de llamada.
15: Su aplicación web realiza una llamada a la API.
17/16/18: la puerta de enlace API verifica el token de acceso, intercambia el token de acceso con un JWT (que contiene información del usuario, …) y reenvía la llamada.
También es posible una configuración en la que el servidor de autorización llame a la puerta de enlace API. En este caso, una vez realizada la autorización, el servidor de autorización pasa el token de acceso y JWT a la puerta de enlace API. Aquí, sin embargo, cada vez que cambia la información del usuario, el servidor de autorización tiene que “informar” a la puerta de enlace API.
Calificaciones y reseñas
Más adelante puedes encontrar las observaciones de otros programadores, tú todavía tienes el poder mostrar el tuyo si te apetece.