Modèles d'intégration OIDC

Les modèles sont strictement présentés du point de vue de l'application. Cela signifie que seul le fournisseur OpenID de l'OIDC est visible pour l'application. La complexité sur la façon dont le fournisseur OpenID obtient une authentification est complètement cachée, à savoir :
  • Dispatching vers le bon fournisseur d'identité (eg. CH-LOGIN ou FED-LOGIN)
  • Conversions de protocoles (de / à SAML) pour parler avec le fournisseur d'identité
  • Logique d'embarquement / demande d'accès
  • Notifications
  • et quelques autres choses encore

Patron "Classique"

Dans ce modèle, l'ID-Token OIDC est utilisé de la même manière qu'un Token SAML. L'ID_Token est utilisé pour établir une session d'application côté serveur. Après avoir établi la session, seul le cookie de session est utilisé pour suivre la session de l'application.

L'OIDC est configuré pour utiliser le flux de code d'autorisation.

Illustration du flux de codes d'autorisation OIDC dans le modèle classique.
Flux de codes d'autorisation OIDC dans le modèle classique.

Pattern ID-Token misuse in SPA (single page applications) with Microservices

Dans ce modèle, l'application est généralement exécutée en tant qu'application à page unique dans le navigateur et appelle les microservices de soutien à l'aide de REST-API protégés par le mécanisme OAuth2.

Ici, l'ID-Token est utilisé pour l'autorisation API des microservices de soutien. Il s'agit d'une mauvaise utilisation du concept OIDC / OAuth2 que nous déconseillons fortement et que nous ne soutenons pas non plus lorsque des problèmes surviennent du côté de l'application.

OIDC est configuré pour utiliser le flux implicite. Pour obtenir une sécurité raisonnable dans ce cas, il faut également utiliser le PKCE.

Image du flux de code d'autorisation OIDC avec abus de jeton d'identification dans SPA avec des modèles de microservices.
Exemple d'utilisation abusive de jeton d'identification dans SPA avec microservices.

Pattern Authorization Server for SPA (single page applications) with Microservices

Dans ce modèle, un serveur d'autorisation est introduit, qui émettra / gérera les jetons d'accès qui sont valides dans la portée de l'application.

Le serveur d'autorisation est sous la responsabilité de l'application (ou du cluster d'application), il n'y a actuellement aucun service de l'eIAM fournissant cette fonctionnalité.

Illustration du serveur d'autorisation de patterns OIDC pour les SPA (Single Page Applications) avec microservices.
Exemple de serveur d'autorisation pour SPA avec microservices.