OAuth 2.0: Der Authorization Code Flow im Detail

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

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

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:

GET {Authorization Endpoint}
?response_type=code // - Um Anzugeben was als Response erwartet wird. Anders als beim Implizit Grant Flow wird beim Initialrequest an den Authorization Server diesmal der Code und nicht das Access Token erwartet
 
&client_id={Client ID} // - Teilauthentifizierung des Clients, Mitteilung darüber welcher Client die Autorisierung beantragt. (Client ID wird zuvor beim Authorization Server hinterlegt, falls der Client sich gegenüber den Authorization Server Authentifizieren muss)

&redirect_uri={Redirect URI} // -  Wohin nach der Authorisierung weitergeleitet werden soll

&scope={Scopes} // -  // - Was kann der Client mit der Autorisierung durchführen.

&state={Arbitrary String} // - Wert zum Schutz vor CSRF (cross site request forgery) Angriffen

&code_challenge={Challenge} // - Werte für PKCS

&code_challenge_method={Method} // - Werte für PKCS

HTTP/1.1
HOST: {Authorization Server}

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:

HTTP/1.1 302 Found
Location: {Redirect URI}
?code={Authorization Code} // - Der Authentication Code
&state={Arbitrary String} // - Siehe request

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:

POST {Token Endpoint} HTTP/1.1
Host: {Authorization Server}
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code // - Mitteilung des Grant Type
&code={Authorization Code} // - Der zuvor erhaltenen Authorization Code
&redirect_uri={Redirect URI} // - Die Gleiche Redirect URI wie beim vorherigen Request.
&code_verifier={Verifier} // - Wert für die PKCS verifizierung

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

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache{
"access_token": "{Access Token}", // - Das Access Token
"token_type": "{Token Type}", // - Die Art des Tokens (z.B. Bearer)
"expires_in": {Lifetime In Seconds}, // - Gultigkeitsbereich des Tokens
"refresh_token": "{Refresh Token}", // - Optional ein Refresh Token
"scope": "{Scopes}" // - Zu was der Client tatsächlich Autorisiert ist
}

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

Wir haben gesehen, dass der OAuth 2.0 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

• https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use
• https://oauth.net/2/grant-types/authorization-code/
• https://oauth.net/2/pkce/
• https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type
• https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85