39 VIEWS

OAuth 2.0: Der Authorization Code Flow im Detail

01.09.2022

Nachdem sich der erste Teil dieser Blogreihe mit den Rollen und deren Aufgaben im OAuth 2.0 Standard für die API Autorisierung beschäftigt hat , werde ich in diesem Teil, speziell den Authorization Code Flow behandeln.

Authorization Code Flow (Optional mit Proof Key for Code Exchange kurz PKCE)

Der Authorization Code Flow kann für klassische Web Apps, Native oder Mobile Anwendungen sowie bei Single Page Applications (SPA) verwendet werden.

Authorization Code Flow
Abbildung 1: Authorization Code Flow; Bildquelle: Eigene Darstellung

Anders als beim Implizit Grant wird bei der Autorisierungsanfrage an den Authorization Server nicht direkt das Access Token zurückgegeben, sondern ein Authorization Code, den der Client in einer weiteren Anfrage an den Authorization Server zum Erhalt des tatsächlichen Accesss Tokens schickt. Das hat den Vorteil, dass dieser Authorization Code als Parameter in der Redirect URL auftauchen kann, ohne das Access Token zu leaken. Um hier Schutz vor Cross-Site-Request-Forgery (CSRF ) Angriffen zu bieten wurde PKCS eingeführt. Bei diesem Verfahren liefert der Client in einer Autorisierungsanfrage einen zusätzlichen Geheimtext, der beim Tausch des Authorization Code gegen das Access Token erneut vorgezeigt werden muss. Ein weiterer Vorteil des Authentication Code Flow ist, dass das Access Token, falls der Browser nicht der Client ist, nicht im Browser persistiert werden muss. Der Browser muss lediglich den Authorization Code peristieren, wodurch das Access Token nicht durch XXS (Cross Site Scripting) oder sonstige Browser basierte Angriffe geleaked werden kann.

 

Erklärung des Flows:

1) Der User (Resource Owner) möchte auf Ressourcen des Resource Servers zugreifen, und klickt auf den Link dorthin.

2) Der Client stellt eine Autorisierungsanfrage an den Authorization Server über dessen /authorization Schnittstelle.

Beispiel Request:

3 4 5) Der Authorization Server liefert dem User eine Login Seite.

6) Bei erfolgreicher Authentifizierung wird dem Client vom “Authorization Server” ein Authentication Code mitgeteilt.

Beispiel Response:

 

7) Der Client frägt beim Authorization Server das Access Token im Austausch mit seinem Authorization Code an. Dieses Mal bei dessen /token Schnittstelle.

Beispiel Request:

 

8) Der Authorization Server liefert bei korrektem Authorization Code das Access Token an den Client.

 

9) Der Client frägt die Ressource beim Resource Server an und präsentiert seinen Token. Dieser validiert die Anfrage und liefert die Ressource .

 

Fazit

Wir haben gesehen, dass der Authorization Code Flow vor allem mit PKCS im Vergleich zum Implicit Flow deutlich mehr Sicherheit bietet. Daher kann dieser als empfohlener Flowtyp für Web Apps, Native oder Mobile Anwendungen sowie bei SPAs angesehen werden. Wer sich nochmal die Probleme des Implicit Flow in Erinnerung rufen möchte, findet die Informationen dazu hier.

 

Mehr über Softwaretechnologien erfahren

 

Quellen

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.

*Pflichtfelder

*