Software Security - OIDC Beispiel

OAuth2/OIDC Beispiel

Hier kannst du deinen OAuth2 / OpenID Connect Request zusammenbauen, um einen Authorization Code abzufragen und diesen dann gegen ein ID-Token einzutauschen.

Client-Konfiguration

OpenID-Configuration URL
(Auth0: Advanced Settings -> Endpoints, Keycloak: Realm Settings -> Endpoints)

OpenID-Configuration Domain muss angegeben werden.

Client ID (Aus Applikation / Client Einstellungen)

Client ID muss angegeben werden.

Nonce (Die Nonce kommt im ID-Token zurück, so kannst du in deiner Single-Page-Application überprüfen, dass dir keiner ein altes oder falsches ID-Token zurückgibt. Die Nonce wird also nur verpflichtend benötigt, wenn du ein Access-Token oder ID-Token zurückbekommen möchtest. Dies kannst du über den response_type steuern.)

Nonce muss angegeben werden.

State (Der State kommt im Redirect zur Callback-URL als Parameter zurück. Du kannst überprüfen, ob der dort erhaltene State zu dem State passt, den du hier gewürfelt hast. So kannst du verhindern, dass jeder von überall deine Callback-URL aufrufen kann. Diese Art Angriff nennt man auch Cross-Site Request Forgery, kurz CSRF.)

State muss angegeben werden.

Code Verifier (Zufallswert für das PKCE-Verfahren beim Authorization Code Flow. PKCE bedeutet Proof Key for Code Exchange, also ein Beweisschlüssel für den Tausch des Authorization Codes. Diesen Wert schickst du nicht mit an den Authorization Server, sondern berechnest zunächst die Code Challenge, also den SHA256-hash des verifiers. Den Verifier merkst du dir nur. Hier passiert das in LocalStorage, so dass wir auf der Callback-Seite wieder auf den Wert zugreifen können.)

Code Verifier muss generiert oder eingegeben werden.

Code Challenge (SHA256 vom Code Verifier. Bei der Anfrage an den Authorization Server wird diese challenge mitgesendet. Auf der Callback-Seite kann man dann per POST-Request von Token Server den erhaltenen Authorization Code gegen ein Access Token tauschen. Bei diesem Request wird dann der Code Verifier mitgeschickt. So kann der Token Server überprüfen, dass die selbe Applikation das Token abruft, welche vorher den Authorization Code abgefragt hat. Das schützt davor, dass jemand den Authorization Code stiehlt und selbst gegen ein gültiges Access-Token tauscht.)

Code Challenge muss berechnet oder eingegeben werden.

Code Challenge Method (Plain oder SHA256. Sollte immer SHA256 sein und ist deshalb hier nicht änderbar.)

Code Challenge Method muss S256 sein.

Redirect-URI

Redirect-URI muss angegeben werden.

Response Type (Mit Leerzeichen getrennt: code token id_token)

Response Type muss code sein.

Scope (Mit Leerzeichen getrennt, z.B. "openid name given_name email")

Scope muss gesetzt sein, z.B. auf openid.

Die per GET aufgerufene URL wird so aussehen: