El proceso habitual es:

• Elija un servidor de autorización (AS), por ejemplo, Okta
• Tus aplicaciones solo interactúan con el AS
• El AS gestiona las conexiones con los desplazados internos por usted

Sus aplicaciones usan una biblioteca de seguridad cuando interactúan con el AS:

• Las API pueden usar JOSE para validar tokens de acceso JWT y obtener claves públicas del AS
• Un React SPA podría usar una biblioteca diferente, por ejemplo, la de Okta que menciona; más sobre esto en breve

Un buen objetivo es mantener el código de la aplicación basado en mensajes estándar de OAuth, de modo que pueda cambiar el AS a uno diferente con cero o solo cambios menores en el código. La biblioteca Okta se ve bien aquí, similar a oidc-client .

Proveedores de identidad

El sistema Okta y su biblioteca están bastante basados en estándares, pero desafortunadamente no todos los IDP lo están. Entonces, si usa la biblioteca Okta para conectarse a OneLogin o Google, es probable que encuentre incompatibilidades y problemas. Si usa un AS, se encargará de esto por usted.

Requisitos

Si está creando React SPA, también debe aclarar el comportamiento que desea en el navegador:

• La biblioteca Okta usa el flujo SPA tradicional y almacena tokens en el navegador. La única forma de que funcione de manera confiable es almacenar tokens de actualización en el almacenamiento local, y esta no se considera la opción más segura.

Para un enfoque más seguro (pero también un flujo más complejo), consulte mi publicación de blog Token Handler .

De todos modos, es de esperar que todo lo anterior le proporcione algunos antecedentes útiles para sus propias elecciones técnicas.

intente utilizar un SDK genérico en lugar del proporcionado por un proveedor de identidad específico si desea admitir varios IdP.

aquí hay un ejemplo: https://github.com/IdentityModel/oidc-client-js