OIDC-Integrationsmuster

Die Muster sind strikt aus der Sicht der Anwendung dargestellt. Das bedeutet, dass nur der OIDC OpenID Provider für die Anwendung sichtbar ist. Die Komplexität, wie der OpenID-Provider eine Authentifizierung erhält, ist vollständig verborgen, nämlich:
  • Dispatching zum richtigen Identity Provider (z.B. CH-LOGIN oder FED-LOGIN)
  • Protokollkonvertierungen (von / zu SAML), um mit dem Identity Provider zu kommunizieren
  • Onboarding / Zugriffsanforderungslogik
  • Benachrichtigungen
  • und ein paar weitere Dinge

Muster "Klassisch"

In diesem Muster wird das OIDC-ID-Token auf die gleiche Weise wie ein SAML-Token verwendet. Das ID_Token wird zum Aufbau einer serverseitigen Anwendungssitzung verwendet. Nach dem Aufbau der Sitzung wird nur noch das Sitzungs-Cookie verwendet, um die Anwendungssitzung zu verfolgen.

OIDC ist für die Verwendung des Autorisierungscodeflusses konfiguriert.

Abbildung des OIDC Autorisierungscodeflusses im klassischen Muster.
OIDC Autorisierungscodefluss im klassischen Muster.

Muster ID-Token-Missbrauch in SPA (Single Page Applications) mit Microservices

Bei diesem Muster wird die Anwendung in der Regel als Single Page Application im Browser ausgeführt und ruft die dahinter liegenden Microservices über REST-APIs auf, die durch den OAuth2-Mechanismus geschützt sind.

Hier wird das ID-Token für die API-Autorisierung der unterstützenden Microservices verwendet. Dies ist ein Missbrauch des OIDC / OAuth2-Konzepts, den wir nicht empfehlen und auch nicht unterstützen, wenn es zu Problemen auf der Anwendungsseite kommt.

OIDC ist so konfiguriert, dass es den Implicit Flow verwendet. Um eine angemessene Sicherheit zu erreichen, muss in diesem Fall auch PKCE verwendet werden.

Abbildung des OIDC Autorisierungscodeflusses mit ID-Token-Missbrauch in SPA mit Microservices Muster.
Muster ID-Token-Missbrauch in SPA mit Microservices.

Pattern Authorization Server für SPA (Single Page Applications) mit Microservices

In diesem Pattern wird ein Authorization Server eingeführt, der die im Anwendungsbereich gültigen Access Tokens ausstellt / verwaltet.

Der Authorization Server liegt in der Verantwortung der Anwendung (oder des Anwendungsclusters), es gibt derzeit keinen Dienst von eIAM, der diese Funktionalität bereitstellt.

Abbildung des OIDC Pattern Authorization Server für SPA (Single Page Applications) mit Microservices.
Muster Authorization Server für SPA mit Microservices.