OIDC Integration patterns
The patterns are strictly shown in application point of view. This means, that only the OIDC OpenID provider is visible to the application. The complexity on how the OpenID Provider gets an authentication is completly hidden, namely:- Dispatching to the right Identity Provider (eg. CH-LOGIN or FED-LOGIN)
- Protocol conversions (from / to SAML) to talk with the Identity provider
- Onboarding / Access Request logic
- Notifications
- and a few more things
Pattern "Classical"
In this pattern the OIDC ID-Token is used the same way as a SAML Token. The ID_Token is used to establish a server-side application session. After establishing the session, only the session cookie is used track the application session.OIDC is configured to use the Authorization Code Flow.
-
- OIDC authorisation code flow in the classic pattern.
Pattern ID-Token misuse in SPA (single page applications) with Microservices
In this pattern, the application usually is run as a single page application in the browser and calls the backing microservices using REST-APIs protected by OAuth2 mechanism.Here, the ID-Token is taken for API Authorization of the backing microservices. This is a misuse of the OIDC / OAuth2 concept we strongly not recommend and also don't support, when there problems on application side arise.
OIDC is configured to use the Implicit Flow. To get reasonable security in this case also PKCE must be used.
-
- Pattern ID token misuse in SPA with microservices.
Pattern Authorization Server for SPA (single page applications) with Microservices
In this pattern an Authorization Server is introduced, which will issue / manage the Access Tokens which are valid in application scope.The Authorization Server is in the responsibility of the application (or application cluster), there is currently no service from eIAM providing this functionality.
-
- Sample authorisation server for SPA with microservices.