Primero autenticaría a los usuarios en su aplicación front-end utilizando cualquier tipo de credenciales y luego, con suerte, generará un token interno que sea válido para la sesión web.
Luego puede exponer el punto final de emisión del token: OAuth, que emitirá un token en función del token de portador entrante, es decir, su sesión web. El punto final de emisión de su token debería poder validar el token web y luego emitir un token OAUth que sea válido en todos sus servicios.
cree un flujo de datos entre usuario, agente (navegador), aplicaciones (front-end) y servicios.
- ¿Qué significan back-end y front-end?
- ¿Qué es un lenguaje de fondo?
- ¿Has conocido a un desarrollador de Full Stack que está entusiasmado con el front-end y el back-end?
- ¿Alguna empresa de desarrollo de sitios web confiable y de buena reputación en China (con sede en Nanjing, Shanghai o cerca)?
- Cómo conectar los puntos entre tutoriales de programación y aplicaciones de la vida real
Su proveedor de OAuth debería poder emitir un token basado en un token de portador (token web) o en credenciales (solo para clientes confidenciales) o con el consentimiento del usuario (similar a lo que hace Facebook y Google).
Sea cual sea el enfoque, necesita un puente para conectarse entre Facebook Auth, su token web (front-end) y un token para acceder a los micro servicios.
Ejemplo práctico
En el software de gestión de clases para después de la escuela, guardería, artes marciales, gimnasia, la aplicación web está protegida por la capa AuthN / AuthZ. Tiene su propio proveedor OAUth. Apoyamos Google / Facebook. Esto funciona bien cuando está dentro de la aplicación web.
Una vez que presentamos la aplicación móvil, con Firebase como back-end, la aplicación móvil necesita autenticarse (no tiene sentido usar Firebase AuthN ya que ya tenemos usuarios en nuestro sistema) contra nuestros servicios. Pero firebase requiere autenticación antes de que pueda leer / escribir en Firebase (no desea hacerlo público).
Aquí está nuestro flujo.
Aplicación móvil: se autenticará con nuestro proveedor OAuth para obtener el token OAuth.
Use el token OAuth para obtener FirebaseToken (Firebase proporciona SDK y soporte para autenticación personalizada). Esto nos permitirá ser proveedores de identidad y crear identidades en Firebase (sinónimo de aplicación web).
Ahora, cuando Firebase necesita hacer llamadas a nuestra API utilizando la función de nube, habilitamos la autenticación basada en tokens (similar a la clave API) que son de corta duración. Entonces, cuando el usuario autenticado escribe en firebase, adjuntamos un token de corta duración. Cloud Functions de firebase usará ese token para llamar a la API adecuada. El token es de corta duración y podemos mantener la identidad del usuario final a través de los límites de la aplicación y el proveedor de la nube.
Así es como puedes separar las cosas.
Proveedor de autenticación externa (SSO / OIDC / lo que sea): que proporciona autenticación.
Token de usuario interno: este es su token interno que genera una vez que la autenticación se realiza correctamente. Crea huella de usuario / identidad, roles y genera un token.
Sesión: cuando hay una sesión como aplicación web, usa el token interno (que se genera, la sesión de horas extra comienza y vence en pocos minutos o se actualiza).
Ahora, cuando tenga que invocar Servicios – En proceso – use Sesión. Fuera de proceso (contenedor de aplicación diferente, micro servicio, etc.): genera un nuevo token que el servicio comprende. Puede ser un token OAuth u otra cosa. Pero el punto es que el token que emite tiene que validar el token interno para emitir un token de mapeo para el servicio de destino.
Enjuague y repita cada vez que cruce el límite.
Para otros ejemplos, mire la autenticación de Firebase y cómo se integran con Cloud Storage y Firebase. Mire AWS y AWS Cognito.
