Clarification sur id_token vs access_token

Question

Je construis un système avec OIDC et OAuth 2.0 (en utilisant Auth0), et je ne sais pas comment utiliser correctement les id_token et access_token. Ou plutôt, je suis confus au sujet des rôles à assigner aux différents services dans ma configuration.

J'ai une application frontend entièrement statique (application d'une seule page, HTML + JS, sans backend) qui garantit que l'utilisateur est authentifié en utilisant le flux implicite contre Auth0. L'application frontend récupère ensuite les données d'une API que je construis également.

Maintenant, ce qui est exact?

• Le SPA frontend est le OAuth application cliente
• Mon service API est un serveur de ressources OAuth

... ou:

• Le frontend et mon Service API sont à la fois l'application client

Si les deux mon API frontend et backend peut être considéré comme le client, je ne vois pas un préjudice réel à l'aide de la id_token comme le jeton porteur sur les demandes de mon frontend à mon back-end - c'est séduisant, car alors je peux simplement vérifier le jeton signé sur le backend, et j'ai toutes les informations sur l'utilisateur dont j'ai besoin. Toutefois, si mon API est considérée comme un serveur de ressources, je devrais probablement utiliser le access_token, mais ensuite je dois me connecter aux serveurs d'Auth0 à chaque demande d'API pour à la fois vérifier le jeton et obtenir des informations utilisateur de base, n'est-ce pas? J'ai lu this qui semble suggérer que le access_token est le seul jeton valide à utiliser avec mon API. Mais comme je l'ai dit, je ne suis pas sûr du rôle des différents services. Et en utilisant le id_token est tentant, car il ne nécessite aucune connexion réseau sur le backend, et contient des informations dont j'ai besoin pour extraire les bonnes données.

Quelle est la bonne façon de procéder?

Answer 1

Votre frontent est votre application client OAuth, une fois qu'il a stocké le jeton et peut effectuer des actions sur le flux OAuth. Et votre service d'API est service de ressources, car il accepte le access_token émis par votre serveur d'identité.

Aussi je dirais que votre id_token représente l'identification de l'utilisateur connecté et peut contenir des données sensibles pour votre application. Le access_token est votre identifiant pour accéder à une ressource. A la fin, vous utiliserez un access_token pour demander une ressource, et si vous avez besoin de données spécifiques de l'utilisateur connecté (propriétaire de la ressource), vous pouvez demander le jeton d'identification à partir du point de terminaison du jeton.