OpenID Connect (OIDC) ist eine Identitätsschicht auf Basis des OAuth-2.0-Protokolls, mit der Anwendungen Nutzer authentifizieren können, ohne deren Anmeldedaten selbst verwalten und speichern zu müssen. Der AWS Application Load Balancer (ALB) lässt sich mit den gängigsten Social-Identity-Providern (IdPs), Unternehmensidentitäten und jedem OIDC-konformen IdP verbinden. Diese Integration vereinfacht die Authentifizierung und erhöht die Sicherheit, weil die Verwaltung von Benutzersitzungen und Authentifizierungstokens an einen vertrauenswürdigen Drittanbieter ausgelagert wird.
Für Endnutzer läuft die Anmeldung reibungslos ab – bricht die Authentifizierung aber durch die zusätzlichen Hops zwischen Nutzer und Zielanwendung ab, wird die Fehlersuche schnell knifflig.
Dieser Artikel zeigt, wie die HTTP-Transaktionen im Authorization-Code-Flow aus den verschiedenen Perspektiven aussehen.
Wenn Sie wissen möchten, wie Sie die Benutzerauthentifizierung an Ihrem ALB einrichten, empfehle ich die offizielle AWS-Dokumentation. AWS stellt zudem eine Demo-Seite bereit, auf der Sie die Authentifizierung selbst ausprobieren können.
**Der Authentifizierungs-Flow Schritt für Schritt –**
Logging ist entscheidend für Stabilität, Sicherheit und Effizienz cloudbasierter Anwendungen. Es liefert die nötigen Einblicke, um Anwendungen zu überwachen und Fehler zu beheben – damit alles reibungslos und sicher läuft.
Um den Authentifizierungs-Flow im Detail nachzuvollziehen, habe ich folgende Logs gesammelt:
- HAR-Datei aus dem Webbrowser des Nutzers.
- Access Logs der IdP-Endpunkte (Auth, Token, User-Info), des ALB und der Zielanwendung.
Bevor Sie sich die HTTP-Transaktionen genauer ansehen, lohnt sich ein Blick auf die verschiedenen OIDC-Komponenten und deren Aufgaben.
Voraussetzungen –
- Der IdP ist für den Authorization-Code-Grant-Flow mit den gewünschten Scopes konfiguriert. Eine Client ID und ein Client Secret wurden ebenfalls erzeugt.
- Der ALB hat eine Listener-Regel, die die Aktion "authenticate" auslöst, sobald der HTTP-Pfad
/auth*lautet. Definieren Sie die Parameter der Authentifizierungsanfrage – Client ID, Client Secret, Authorization Endpoint, Token Endpoint und User Info Endpoint. Über diese Parameter kommuniziert der ALB mit dem IdP.
Schritt 1 – Der Nutzer schickt eine HTTP-Anfrage an Ihre Anwendung hinter einem ALB mit aktivierter Authentifizierung.
Der Browser wird zum Auth-Endpunkt des IdP weitergeleitet.
ALB-Access-Logs derselben Transaktion –
h2 2024–07–11T18:47:52.382721Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302–359 657 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" arn:aws:elasticloadbalancing:eu-west-1:21112316:targetgroup/TG/1a24c5faad770fb2 "Root=1–669028d8–653487fd74af592f498329f8" "authenticate"
- Die Authentifizierungsaktion wird ausgelöst, sobald der Nutzer einen HTTP-GET-Request an den ALB schickt.
- Liegt in den HTTP-Request-Headern kein Authentifizierungs-Session-Cookie vor, antwortet der ALB mit HTTP 302 und leitet den Nutzer an die im Location-Header angegebene URL weiter (den Authorization-Endpunkt des IdP).
- Die
redirect_urigibt das Ziel an, zu dem der Browser weitergeleitet wird, sobald der IdP den Authorization Code ausgestellt hat.
Schritt 2 – Der Nutzer wird zum Authorization-Endpunkt des IdP weitergeleitet.
HTTP-Anfrage an den Auth-Endpunkt.
- Der Nutzer schickt eine HTTP-Anfrage an den Authorization-Endpunkt des IdP.
- Der Authorization-Endpunkt leitet ihn anschließend zum Login-Endpunkt des IdP weiter (
/login). - Der Login-Endpunkt übernimmt die eigentliche Authentifizierung.
Schritt 3 – Der Nutzer ruft den Login-Endpunkt auf.
HTTP-Anfrage an den Login-Endpunkt.
- Der Nutzer schickt eine HTTP-Anfrage an den Login-Endpunkt.
- Die Login-Seite wird mit den Feldern für Benutzername und Passwort geladen.
Schritt 4 – Der Nutzer authentifiziert sich.
Der Nutzer gibt Benutzername und Passwort ein.
- Der Nutzer trägt seine Anmeldedaten auf der Login-Seite des IdP ein.
- Nach erfolgreicher Authentifizierung wird er zurück zum Authorization-Endpunkt des IdP geleitet.
Beispiel-Payload des POST-Requests –
csrf=izvsVKMB-GxnSvAK6McnPw6uNcZVCqqWxjeU&challenge=cbcab3062ca041399178171a4078d30b&email=user%40name.com&password=complex&submit=Log+in
Schritt 5 – Der Nutzer erhält den Authorization Code vom IdP.
Auth Code wurde ausgestellt.
- Der Authorization-Endpunkt des IdP leitet den Nutzer mitsamt Authorization Code zurück zur Client-Anwendung.
- Die ursprünglichen Werte des
state-Parameters bleiben erhalten, um eine 1:1-Beziehung zwischen Anfrage und Callback sicherzustellen.
Schritt 6 – Der Nutzer kehrt mit dem Authorization Code zum ALB zurück.
Der Nutzer wird mit Authentifizierungs-Cookie zurück zu /auth weitergeleitet.
ALB-Access-Logs derselben Transaktion –
h2 2024-07-11T18:48:27.805659Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302 - 423 847 "GET https://demo.aws.doit.com:443/oauth2/idpresponse?code=ory_ac_9j6SCghDyFOexN03pTRP_GSJ5RHduhCLE-L74D2IlSs.zMsOhvXLbIrs0WQLtb43tkUnRZm0lWoI5T0IlNjnoO0&scope=openid&state=Y06EN0RLaODTpBbHGEpfK29AZJcLIpftyWwbyQN8EeiFyOtbN07H2nTXTGUa3DDYX5UgeMDsqP9psViZhPy41Y%2FVkNoJc5%2B6jb8po%2BLXQtcgxRgk9s5T0LgWt53mOEOjxL4nBVQ9Z9X1Sm%2BcZNO%2BFAIlh%2B6t99WKKj3vz1bekHiwdLWp18GUo9cp3eUkPWXbSBXprXOUHk2QlPK9xd7sG3AHyj4urRv3lc97AR4DRrVIECUMOsNP5BlYW6%2FGAg%3D%3D HTTP/2.0" "Root=1-669028fb-6e750f6c5c7fdde45853b7f6" "authenticate"
- Der Nutzer übergibt den Authorization Code an den ALB.
- Der ALB antwortet mit HTTP 302 und leitet den Nutzer zurück zur ursprünglichen URI:
https://demo.aws.doit.com/auth.html. - Vor dem Erzeugen der Antwort sendet der ALB Backchannel-Anfragen an folgende Endpunkte:
Token-Endpunkt des IdP, um den Code gegen ein IdToken einzutauschen.
POST-Request an den Token-Endpunkt.
UserInfo-Endpunkt, um das Access Token gegen User Claims einzutauschen.
Anfrage an den UserInfo-Endpunkt.
User Claims, Access Token und Refresh Token werden base64-codiert, verschlüsselt und im Cookie AWSELBAuthSessionCookie abgelegt.
Schritt 7 – Der Nutzer ruft die ursprüngliche URI mit gesetztem AWSELBAuthSessionCookie auf.
Der ALB authentifiziert den Nutzer, und die Anfrage erreicht das Backend.
ALB-Access-Logs derselben Transaktion –
h2 2024-07-11T18:48:27.824183Z app/demo/25be909a3f190764 109.78.96.82:54871 172.31.11.119:80 0.007 0.001 0.000 200 200 596 3307 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" "arn:aws:elasticloadbalancing:eu-west-1:211125377316:targetgroup/healthyTG/1a24c5faad770fb2 "Root=1-669028fb-156c503c2fe1fcdb60e4a5ad" 2024-07-11T18:48:27.815000Z "authenticate,forward" "172.31.11.119:80" "200"
- Die Regelbedingungen am ALB für die Aktion "authenticate" sind erfüllt, und der Authentifizierungs-Cookie liegt ebenfalls vor.
- Der ALB validiert den Cookie und reicht die Nutzerinformationen über die HTTP-Header
X-AMZN-OIDC-*an die Targets weiter.
X-AMZN_OIDC*-Header, wie sie am Target ankommen –
X-AMZN_OIDC*-Header.
x-amzn-oidc-accesstoken– das Access Token vom Token-Endpunkt.
x-amzn-oidc-identity– das Subject-Feld (sub) vom UserInfo-Endpunkt.
x-amzn-oidc-data– die User Claims im JSON-Web-Token-Format (JWT).
Die User Claims im JWT-Format bestehen aus Header, Payload und Signatur, jeweils base64-URL-codiert. Für die JWT-Signatur nutzt der ALB ES256 (ECDSA mit P-256 und SHA256).
Decodiertes JWT –
Der JWT-Header ist ein JSON-Objekt mit Issuer, Signer-Details und Key ID. Der JWT-Payload ist ein JSON-Objekt mit den User Claims, die der UserInfo-Endpunkt des IdP geliefert hat.
Das Target (Apache) autorisiert den Nutzer anhand der Claims und schickt eine HTTP-200-OK-Antwort über den ALB zurück an den Nutzer.
Fazit –
Dieser Artikel zeigt im Detail, wie die HTTP-Transaktionen im OIDC-Authorization-Code-Flow am AWS Application Load Balancer (ALB) ablaufen. Jeder Schritt – von der ersten HTTP-Anfrage des Nutzers bis zur abschließenden Authentifizierung und Autorisierung – wird einzeln aufgeschlüsselt, inklusive der wichtigsten HTTP-Interaktionen und Logging-Details, die für Troubleshooting und das Verständnis des Ablaufs unverzichtbar sind.
Wenn Sie mehr erfahren möchten oder an unseren Services interessiert sind, sprechen Sie uns gerne an. Sie erreichen uns hier.