Utilisation d'openid-connect pour l'authentification spa et repos api

Question

J'ai un serveur API (serveur de ressources) et plusieurs applications, interface graphique Web (SPA) et un client de bureau et peut-être plus à venir. Je voudrais utiliser openid-connect en plus de l'authentification de base HTTP pour mon API Server. Il devrait être configurable quel fournisseur openid utiliser. Mon propre, facebook, google ... Je veux seulement faire l'authentification, je n'ai pas besoin de leur API. J'ai seulement besoin de certaines données de profil comme l'email ou le prénom. Supposons que j'ai configuré google en tant que fournisseur d'identité et que j'utilise actuellement mon interface graphique Web (SPA). Je dois me connecter, pas de problème, selon https://developers.google.com/identity/protocols/OpenIDConnect Je redirige l'utilisateur vers google, obtient mon code d'autorisation et le Web Gui (SPA) obtient un id_token et access_token de google.

Aucun problème jusqu'à présent, mais maintenant le SPA doit fonctionner avec mon serveur API et le serveur API doit authentifier chaque requête (puisqu'il s'agit d'une api de repos sans état) provenant du client (WebGui SPA) et doit savoir quel utilisateur a réellement fait cela.

A

Ainsi, le access_token de Google est destiné à être utilisé pour accéder au droit de google api? Mais je pourrais également passer ce access_token avec chaque requête à mon serveur api et le serveur api appelle https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=xxx pour vérifier le access_token et obtenir le nom du compte (mail). Mais cela ne semble pas correct, n'est-ce pas?

B

J'ai aussi et id_token que je peux vérifier sans appeler chaque serveur Google. Alors, est-ce que je pourrais juste passer le id_token en tant que porteur avec chaque demande à mon serveur d'api et le serveur d'api peut vérifier le id_token? Mais selon openid-connect spec le access_token est en fait celui qui vient d'être passé au serveur api et le id_token doit rester sur le client. Mais alors le id_token serait complètement inutile pour moi, le serveur API doit savoir qui est l'utilisateur, le client (interface graphique Web) ne s'en soucie pas vraiment.

C

Ou puisqu'il est mon propre API Server, que mon API serveur a réellement besoin pour mettre en œuvre l'ensemble du système oauth2 par lui-même, tout simplement pas l'authentification mais la création access_token et plus encore. Donc j'aurais un/api/tokensign auquel je peux passer l'id_token de google, l'API vérifie le id_token et crée un access_token pour mon WebGUI (SPA). Et ce nouveau access_token peut être passé en tant que support à chaque requête api. Cela semble être la meilleure solution selon les spécifications, mais ai-je vraiment besoin d'implémenter oauth2 par moi-même dans mon API? Cela ressemble à une addition lourde puisque A et B pourraient aussi être implémentés.

Mon repos-api a besoin d'une authentification à chaque requête, alors A, B, C sont-ils la bonne approche? S'il vous plaît, ne me dites pas que c'est basé sur l'opinion, ce n'est pas le cas. Quelle est la bonne façon d'utiliser oauth2/openid-connect pour l'authentification?

Answer 1

Vous pouvez utiliser les trois méthodes que vous avez mentionnées ci-dessus, mais en fait avec quelques considérations. Je vais les expliquer en ce qui concerne les spécifications disponibles.

Scénario - Deux systèmes S1, S2

• S1 - fournisseur d'identité
• S2 - point final API

Qu'est-ce que vous avez besoin - dépôt et en utilisant 'jetons' émis par S1 pour accéder S2

Explications pour solutioins proposées A, B et C

A- Vérifier les jetons délivrés par S1 pour chaque appel

Cela peut être fait en utilisant le RFC7662 - Point de terminaison OAuth 2.0 Token Introspection. Cette validation est valide par la spécification donc oui, vous pouvez utiliser le point de fin de vérification de jeton.

L'avantage de cette méthode est que, si un jeton est révoqué, l'effet est instantané. L'appel API suivant échouera. Mais en effet, il y a l'implication sur la performance. Vous avez besoin d'un appel de service de vérification supplémentaire.

Notez que vous n'avez pas besoin d'obtenir le nom du compte à partir de cette réponse de vérification. Il pourrait être pris à partir du jeton d'identité et pourrait être utilisé pour vérifier une protection supplémentaire.

B- jetons de fiducie émis par S1 pour chaque appel

Maintenant, cette approche est quelque chose étendue de RFC6750 - Le OAuth Framework 2.0 Autorisation: Bearer Token utilisation. Vous pouvez en effet utiliser ID toke pour authentifier et autoriser un utilisateur final. Cette link contient une bonne explication sur l'utilisation du jeton d'identification en tant que jeton de support.

Vous pouvez en effet vérifier la validité du jeton en utilisant MAC et même le cryptage. Mais soyez conscient d'utiliser des jetons de courte durée et d'utiliser toujours le TLS. Et gardez à l'esprit les jetons rafraîchissants! Parce que selon la spécification openID connect, le jeton d'identification n'est pas un élément obligatoire pour une demande de jeton d'actualisation.

C- Une enveloppe pour la fédération

Pour cela, vous pouvez écrire votre propre solution ou utiliser une des solutions existantes (ex: - WSO2 identity server). Ce serveur d'identité sera configuré pour choisir le fournisseur d'identité sur votre application (client comme application de bureau ou application web). Le serveur d'identité effectuera les redirections nécessaires et vous fournira les jetons requis. Mais en effet, vous devrez utiliser le point d'introspection pour valider la validité du jeton.

Si vous avez une longueur d'avance sur cette solution, vous pouvez essayer d'implémenter un mécanisme d'échange de code.Vous pouvez échanger le jeton carry d'external vers tokens émis en interne par l'un de vos systèmes (ex: - jeton d'accès Google à votre jeton d'accès interne). L'avantage de cette approche est que vous avez le contrôle sur la validation. De plus, puisque les validations de jetons suivantes sont effectuées en interne, il devrait y avoir une amélioration des performances.

Espérons que cela explique certains doutes que vous avez.