OIDC: ¿cuál es el punto de dos tokens separados: access e id?

1

Me cuesta entender por qué no tenemos un solo token que sirve para ambos propósitos: ¿autorización y autenticación?

En cierto sentido, el token de acceso hace más que solo autorización. También proporciona una identificación de usuario (en la subreivindicación) y, después de la verificación, la API (audiencia del token) sabe quién eres y qué puedes hacer.

Por otra parte,

el token de identificación está destinado al cliente, pero en el caso de un SPA, realmente no veo ningún punto en ello. Un SPA recupera ambos tokens, elimina el token de ID y usa el token de acceso para comunicarse con una API.

Algunas preguntas: - ¿Es solo por razones históricas, que estamos atrapados con dos fichas separadas? - ¿Cuándo necesito realmente el token de identificación? ¿Qué hace un SPA con eso?

    
pregunta eddyP23 17.07.2018 - 14:15
fuente

1 respuesta

1

El siguiente enlace me ayudó a comprender cómo podría suceder si usamos el token de acceso de OAuth2 para la autenticación, que se denomina pseudo-autenticación:
enlace

Como lo entiendo, el token de identificación en OIDC sirve solo como una prueba para la aplicación cliente de que el propietario del recurso se autenticó en el servidor de autenticación, y el token de acceso se usa para decirle a la aplicación del Cliente solicitante qué recursos tiene el usuario (propietario del recurso) Cliente) y servidor de autenticación tal vez (punto final de información del usuario). Luego, el cliente podría pedirle al usuario (propietario del recurso) que le otorgue acceso a otros recursos, en otros Clientes, y ese acceso podría proporcionarse al Cliente solicitante en forma de otro token de acceso o al mismo tiempo cuando se realiza la autenticación.

Creo que sería útil para usted ver mi propia pregunta reciente, donde proporciono mis propias preguntas sobre cómo funciona OIDC y solicito validación:
Autorización en la aplicación OAuth2 que es cliente y servidor de recursos

Y con respecto al token de identificación para un SPA, tampoco veo el punto. Dado que SPA es como el usuario (propietario del recurso), es como el usuario solicitó una prueba de la autenticación que hizo él mismo. Creo que está ahí solo para hacer que los flujos de trabajo sean uniformes.

    
respondido por el Mike 29.07.2018 - 18:21
fuente

Lea otras preguntas en las etiquetas