Die Rollverteilung im OAuth 2.0 Standard verstehen und Vorstellung des Implizit Flow
OAuth 2.0 ist ein Standard für die sichere API-Autorisierung. Der Standard definiert unterschiedliche Rollen und Abläufe, die oft missverstanden werden. Welche Rollen es gibt und was deren Aufgaben sind, erfahrt ihr hier.
Mit OAuth 2.0 wird die Möglichkeit geschaffen, dass Anwendungen auf geschützte Ressourcen eines externen Service zugreifen können, ohne dass diese Anwendungen den Benutzernamen oder das Passwort zu diesem Service erfahren. Der Standard definiert unterschiedliche Rollen, die oft missverstanden werden. Um mit diesen Missverständnissen aufzuräumen, folgt eine Beschreibung zu den existierenden Rollen. Im OAuth 2.0 Standard werden außerdem unterschiedliche Abläufe, die sogenannten Flows, auch Grant Types genannt, definiert. Durch den Einsatz der verschiedenen Flows lassen sich unterschiedliche Szenarios umsetzen. In diesem Blog, wird der Implizit Flow, der teilweise als unsicher angesehen wird beschrieben. Die übrigen Flows werden in kommenden Blogs behandelt werden.
Rollenverteilung bei OAuth 2.0
Die Rollen in der OAuth 2.0 Spezifikation definieren die einzelnen Komponenten und bestimmen genau, welche Aufgaben diese erfüllen müssen.
Um die Rollenverteilung besser verstehen zu können, soll folgendes Szenario als Anhaltspunkt dienen: Angenommen, der Benutzer „Max Mustermann“ verwendet eine Web-Anwendung „XYZ“ über den Browser, die es ermöglicht Nachrichten von verschiedenen sozialen Netzwerken anzuzeigen, darunter z.B. auch die von „ABC Social Network“.
Dann muss Max Mustermann der Web-Anwendung die Erlaubnis erteilen, auf die Nachrichten, die er auf „ABC Social Network“ erhalten hat, zugreifen zu können.
Um sich den allgemeinen Ablauf von OAuth 2.0 besser vorstellen zu können und den Beschreibungen der Rollen unten besser folgen zu können, soll folgende Grafik helfen.
Sie zeigt den „Implizit Flow“
Client
Der Client ist derjenige, der mit einer geschützten Ressource des Resource Owners arbeiten bzw. darauf zugreifen möchte.
Im Beispiel ist dies die Clientanwendung von „XYZ“, die, um Nachrichten von „ABC“ anzuzeigen, die Erlaubnis des Resource Owners „Max Mustermann“ benötigt.
Resource Owner
Der Resource Owner ist derjenige, der Zugriff auf eine geschützte Ressource gestattet. Er ist also derjenige, der einer Anwendung die Erlaubnis erteilt, stellvertretend auf eine seiner geschützten Ressourcen zugreifen zu können.
Im Fall des Beispiels ist der Resource Owner also „Max Mustermann“, welcher der Webanwendung „XYZ“ gestattet, auf seine Nachrichten auf „ABC“ zugreifen zu können, um diese anzuzeigen.
Authorization Server
Um einem Client die Möglichkeit zu bieten, Zugriff auf eine geschützte Ressource zu erlangen, ohne dass dieser die Benutzeranmeldeinformationen (Username/Passwort) des Resource Owners kennt und mitbekommt, wird ein Authorization Server verwendet.
Dieser bietet dem Resource Owner die Möglichkeit sich bei diesem zu authentifizieren, wodurch der Authorization Server dem Client stellvertretend eine Autorisierung für den Zugriff auf die geschützte Ressource ausstellen kann.
Diese Autorisierung wird dem Client in Form eines Zugriffstokens ausgestellt, über den der Client Zugriff auf die geschützte Ressource des Resource Owners erhält.
Im Beispiel könnte der Authorization Server von „ABC“ dem Client von „XYZ“ einen Zugriffstoken ausstellen, mit dem er Zugriff auf die Nachrichten von „Max Mustermann“ auf „ABC“ erhalten kann.
Zuvor muss „Max Mustermann“ sich jedoch auf dem Authorization Server authentifizieren, z.B. durch einen Login Dialog, sodass dieser dem Client das Zugriffstoken ausstellen kann.
Resource Server
Der Resource Server verwaltet die geschützten Ressourcen des Resource Owners und empfängt die Zugriffsanfragen des Clients. In einer solchen Zugriffsanfrage legt der Client dem Resource Server seinen, vom Authorization Server erhaltenen, Zugriffstoken vor.
Dieses Zugriffstoken wird dann vom Resource Server validiert. Bei erfolgreicher Validierung liefert der Resource Server dem Client dann die angefragte Ressource.
Im Beispiel würde der Client von „XYZ“ mit seinem vom Authorization Server erhaltenen Zugriffstoken die Nachrichten auf dem Resource Server von „ABC“ anfragen. Das könnte z.B. ein API Server sein.
Die OAuth 2.0 Flows
Die eingesetzten Flows geben die genauen Arbeitsschritte vor, die ein Client erledigen muss, um Zugriff zu einer Ressource zu erhalten. Sie geben sozusagen den OAuth 2.0 Workflow vor. Hier gibt es unterschiedliche Flows, um verschiedene Szenarien umsetzen zu können.
Folgende Flows existieren:
- Implizit Flow
- Authorization Code Flow
- Authorization Code Flow mit Proof Key for Code Exchange (PKCE)
- Resource Owner Credentials Grant
- Client Credentials Flow
- Device Authorization Flow
- Refresh Token Flow
Implizit Flow bei OAuth 2.0
Der Implizit Flow, dessen Ablauf bereits in der Rollenverteilung im OAuth 2.0 Standard gezeigt wurde, findet hauptsächlich in SPA (Single-Page-Applications) Anwendung. Also dort, wo der Client direkt der Browser ist und die Anfragen ausführt.
Bei diesem Flow wird dem Client direkt vom Authorizaton Server das Access Token zurückgegeben. Das Token kann entweder direkt als Parameter in der zurückgegebenen Redirect URl oder als Rückgabe eines Form Post vom Client erhalten werden.
Die erste Möglichkeit wird als veraltet angesehen, da diese als unsicher gilt. Gründe hierfür sind folgende:
- Spoofing der Redirect URI bei schlechter Validierung. Dadurch könnte ein Angreifer den Redirect auf einen Server, den er kontrolliert, umleiten und das Access Token auslesen.
- Die URI verbleibt in der Browser Historie und somit auch das Access Token, da es als Parameter in der URI steht.
- Häufig verbleibt die URI im Log, wer also Zugriff auf das Log hat, kann das Access Token auslesen.
Die Variante das Access Token als Parameter in der Redirect URI zurückzugeben, stammt noch aus Zeiten, zu denen es kein CORS (Cross-Origin Resource Sharing) gab und ist daher überholt.
Aus diesem Grund wird für SPAs empfohlen, den Authorization Code Flow mit Proof Key for Code Exchange (PKCE) zu verwenden.
Erklärung des Flows:
1) Der User (Resource Owner) möchte auf Ressourcen des Resource Server 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=token // – Hier wird angegeben was für eine Art von Response erwartet wird. Beim Implizit Flow wird direkt das Access Token erwartet, daher token. &client_id={Client ID} // – Teilauthentifizierung des Clients, Mitteilung darüber welcher Client die Autorisierung beantragt. (Die Client ID wird zuvor beim Authorization Server hinterlegt) &redirect_uri={Redirect URI} // – Angabe des Clients wo dieser zu erreichen ist. &scope={Scopes} // – Was kann der Client mit der Autorisierung durchführen. &state={Arbitrary String} // – Wert zum Schutz vor CSRF (cross site request forgery) Angriffen HTTP/1.1 |
3 4 5) Der Authorization Server liefert dem User eine Login Seite.
6) Bei erfolgreicher Authentifizierung wird dem Client vom Authorization Server das Access Token mitgeteilt.
Beispiel Response:
| HTTP/1.1 302 Found Location: {Redirect URI}#access_token={Access Token} // – Zugriffstoken welches als Parameter in der Redirect URI enthalten ist (Gilt als unsicher und deprecated)&token_type={Token Type} // – Art des Token (z.B. Bearer)&expires_in={Lifetime In Seconds} // – Ablaufzeitraum des Token&state={Arbitrary String} // – Siehe Request&scope={Scopes} // – Zu was der Client tatsächlich Autorisiert ist |
7) Client frägt die Ressource beim Resource Server an und präsentiert seinen Token. Dieser validiert die Anfrage und liefert die Ressource.
Fazit
Der Implizit Flow kann für SPAs verwendet werden, es sollte jedoch vermieden werden, dass Access Token direkt in der Redirect URI anzugeben, da dies als unsicher gilt. Wer also auf Nummer sicher gehen möchte, sollte den Authorization Code Flow mit Proof Key for Code bevorzugt verwenden.
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/implicit/
- https://curity.io/resources/learn/oauth-implicit-flow/
- https://auth0.com/intro-to-iam/what-is-oauth-2/
- https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85
