tutorial sso example auth oauth-2.0 single-sign-on single-page-application openid-connect auth0

oauth 2.0 - example - Solución/arquitectura Single Sign On(SSO) para Single Page App(SPA)



auth0 tutorial (1)

He estado investigando la solución de SSO para SPA por algún tiempo. Hay muchas soluciones con diferencias sutiles, aunque también descubrí que no todos tienen la misma comprensión de SSO y que no existen muchos patrones establecidos de SSO para SPA. Por lo tanto, no estoy pidiendo un diseño / arquitectura detallada, solo trato de ver si hay alguna práctica común sobre este tema.

¿Qué quiero decir con SSO?

  1. Tenemos algunas SPA nuevas en desarrollo (también aplicaciones potencialmente móviles y tabletas), que se implementarán en diferentes servidores y tendrán diferentes dominios.
  2. También tenemos un IdP central (authServer) donde se almacenará toda la identificación del usuario.
  3. Una vez que inicie sesión en SPA1 y haga clic en un botón que me lleva a SPA2 (o SPA3 , SPA4 , potencialmente), no es necesario que ingrese las credenciales del usuario y se iniciará sesión automáticamente.

¿Cuál es la diferencia para SPA? (a diferencia de la aplicación web normal)

He analizado algunas soluciones, incluso antiguas, como SAML (solo quiero tener una idea de SSO ...). mi candidato actual es OpenId Connect , pero luego me di cuenta de una diferencia para SPA, si mi comprensión es correcta: a diferencia de las aplicaciones web normales, SPA generalmente no tiene (o tratamos de no tener) un servidor de back-end. Lo que SPA tiene es solo un servidor que sirve páginas estáticas junto con scripts, hojas de estilo e imágenes.

Ahora viene el problema:

OpenId Connect se basa en el tipo de concesión de OAuth2 Authorization Code , que significa:

  1. Necesito un módulo similar al proxy de back-end para cada SPA si quiero que funcione.
  2. Utilizo una solución diferente para hacer SSO en el lado del cliente, como el que proporciona auth0
  3. No he encontrado ninguna otra solución / ejemplos

Mi pregunta:

Para el punto 1 anterior, ¿es correcto mi entendimiento? ¿Es mejor no permitir que SPA tenga un código de back-end como una aplicación web normal?

Para el punto 2 anterior, eso suena como una solución, pero ¿cómo es eso esencialmente diferente al tipo de concesión implícita OAuth2 ?

Y, ¿hay otras soluciones (marco, protocolo, etc.) que deba saber pero que aún no haya explorado?

Además del perfil de cliente básico que utiliza la concesión del código de autorización, OpenID Connect tiene un perfil de cliente implícito que se basa en la concesión Implict de OAuth 2.0. Este perfil permite que los tokens se entreguen directamente a clientes en el navegador / Javascript sin involucrar un back-end.