OpenID Connect Flows

Login-Flow

• Der Java-Client startet und meldet dem Broker im ersten Request dass er OpenID Connect kann.

• Der Broker fragt beim Authentication Service nach den Einstellungen für OpenID Connect und meldet diese an den Java-Client zurück. Diese sind

  • die Auth-Url des Identity-Providers,
  • die Client-ID und
  • die Scopes.

• Der Java-Client startet einen lokalen HTTP-Server für den Aufruf der Callback-Seite. Diese hat folgende Url: http://localhost:<port>/login-callback

• Der Java-Client ruft über den Standard-Browser die Anmelde-Seite des Identity-Providers auf. Dabei kommt die Auth-Url zum Einsatz. Übergeben werden der Seite

  • die Client-ID,
  • eine im Client erzeugte Code-Challenge und
  • die URL der Callback-Seite.

• Bei erfolgreicher Anmeldung leitet der Identity-Provider uns zur Callback-Seite weiter. Dieser wird ein Anmelde-Code übergeben, mit dem die nächsten Schritte vollzogen werden können. Der Anmelde-Code wird ausgelesen und der lokale HTTP-Server wieder beendet.

• Der Java-Client schickt für die weitere Anmeldung die folgenden Informationen zum Broker:

  • den Anmelde-Code,
  • die Code-Challenge und
  • die URL der Callback-Seite.

• Der Broker leitet diese Informationen an den Authentication-Service weiter, welcher die nächsten Schritte für die Authentifizierung übernimmt.

• Am Identity-Provider wird der Token-Endpoint aufgerufen, um den Anmelde-Code in einen JWT-Token umzuwandeln. Dem Endpoint werden folgende Informationen übergeben:

  • der Anmelde-Code,
  • die Callback-Url,
  • die Client-ID,
  • die Code-Challenge und
  • wenn konfiguriert das Client-Secret.

  Der Identity-Provider liefert folgende Informationen:

  • den JWT-Token - dieser hat nur eine begrenzte Gültigkeit
  • einen Refresh-Token für die Ermittlung eines neuen JWT-Token - dieser ist in der Regel viele Tage gültig.

• Der JWT-Token wird validiert. Es wird sowohl die inhaltliche als auch die kryptographische Korrektheit geprüft. Dabei werden die von Identity-Provider bereitgestellten kryptographischen Schlüssel verwendet.

• Aus dem JWT-Token wird der Claim (in der Regel die Email-Adresse) ausgelesen. Damit wird der entsprechende Benutzer ermittelt und ein XML-Token erstellt. Mit diesem XML-Token kann die Anwendung den Benutzer identifizieren.

• Der Refresh-Token wird in SessionData gespeichert. Damit kann beim nächsten Start der Anwendung der Refresh-Flow angewendet werden.

• Die Anwendung startet mit dem angemeldeten Benutzer.

Refresh-Flow

• Der Java-Client startet und meldet dem Broker im ersten Request dass er OpenID Connect kann.

• Der Broker fragt beim Authentication Service nach den Einstellungen für OpenID Connect.

• Der Broker prüft dann, ob es in SessionData einen gespeicherten Refresh-Token für den Client gibt.

• Der Broker leitet den Refresh-Token an den Authentication-Service weiter, welcher die nächsten Schritte für die Authentifizierung übernimmt.

• Am Identity-Provider wird der Token-Endpoint aufgerufen, um den Refresh-Token in einen neuen JWT-Token umzuwandeln. Dem Endpoint werden folgende Informationen übergeben:

  • der Refresh-Token,
  • die Client-ID,
  • der Scope und
  • wenn konfiguriert das Client-Secret.

  Der Identity-Provider liefert folgende Informationen:

  • den JWT-Token und
  • einen (ggf. aktualisierten) Refresh-Token.

• Der JWT-Token wird validiert. Es wird sowohl die inhaltliche als auch die kryptographische Korrektheit geprüft. Dabei werden die von Identity-Provider bereitgestellten kryptographischen Schlüssel verwendet.

• Aus dem JWT-Token wird der Claim (in der Regel die Email-Adresse) ausgelesen. Damit wird der entsprechende Benutzer ermittelt und ein XML-Token erstellt. Mit diesem XML-Token kann die Anwendung den Benutzer identifizieren.

• Der aktualisierte Refresh-Token wird in SessionData gespeichert.

• Die Anwendung startet mit dem angemeldeten Benutzer.

Note

Wenn die Authentifizierung mit dem Refresh-Token fehlschlägt, erfolgt die Anmeldung über den normalen Login-Flow.