Ein Grant für alle Fälle?
Mit der Entscheidung auf die Standards OAuth2 in Verbindung mit OpenID Connect (OIDC) zu setzen erhöht man u.a. die Sicherheit seiner Clients und seiner APIs. Dazu bietet OAuth2 verschiedene Möglichkeiten (Grant Types) zur Integration, welche bei Fehlanwendung eher zum Gegenteil führen.
OpenID Connect ist ein Authentifizierungsschicht die auf dem OAuth2 Standard aufsetzt.
Flow vs. Grant
„Heißt das jetzt Flow oder Grant oder ist das das gleiche?“ – OIDC beschreibt für die Authentifizierung 3 verschiedene Flows – den Authorization Code Flow, den Implicit Flow und den Hybrid Flow. Wohingegen das OAuth2-Protokoll verschiedene Grant Typen beschreibt. Welche das sind und welche Kriterien für die Auswahl des richtigen Grant-Types entscheidend sind, wollen wir in diesem Blog näher betrachten.
Seit der Veröffentlichung von oauth2 im Jahre 2012 hat sich die Anzahl an Grant-Types immer wieder geändert. So gab es am Anfang u.a. die Grant-Types Implicit Grant und den Ressource Owner Password Credentials Grant, welche mittlerweile aber abgekündigt sind und im aktuellen Entwurf der Spezifikation von oauth2.1 komplett entfernt wurden (Siehe https://oauth.net/2.1/). Daher werden wir auf beide Grant-Typen nicht näher eingehen.
Zur Auswahl stehen somit noch
- Client Credentials
- Authorization Code
- PKCE
- Device Code
- Refresh Token
Diese Liste kann weiter gekürzt werden, wenn man der aktuellen Spezifikation von oauth2.1 Glauben schenken darf. Dort heißt es nämlich, dass der Authorization Code Grant in allen Anwendungen durch den PKCE Grant ersetzt werden sollte. Bisher war das nur bei Clientseitigen Webapplikation und bei mobilen Apps der Fall.
Der Refresh Token Grant ist ein spezieller Grant und kann nicht allein verwendet werden. Bevor man diesen Grant verwenden kann, muss man sich über den Authorization Code Grant, den PKCE Grant oder dem Device Code Grant einen Access-Token und einen Refresh-Token abgeholt haben.
Nach aktuellem Stand wird oauth2.1 unsere Entscheidung, welchen Grant-Typ wir verwenden sollten, also deutlich vereinfachen. Um uns für einen der 3 verbliebenden Grant-Typen zu entscheiden, müssen wir maximal 2 Fragen beantworten.
1. Hat unsere Anwendung Benutzerinteraktion?
Bsp. Nein: Unsere Anwendung ist bspw. ein Cronjob, der jede Nacht Berichte erstellt und dabei Wetterdaten abfragt. Den Access-Token zur Abfrage der Wetterdaten bekommt der Cronjob mit Hilfe seiner Client-ID und seinem Client-Secret über den Client Credentials Grant.
Bsp. Ja: Weiter zu Frage 2
2. Hat das Zielgerät einen Browser und besteht für den Benutzer die Möglichkeit seine Zugangsdaten komfortabel anzugeben?
Bsp. Nein: Unsere Anwendung läuft auf Smart-TVs und stellt verschiedene Filminhalte bereit. Da die Usability zur Eingabe der Zugangsdaten eingeschränkt ist, holt sich die Anwendung den Access-Token über den Device Code Grant.
Bsp. Ja: Unsere Anwendung ist ein Webshop. Anmelde- und Registrierungsseiten können dem Benutzer in jeder Form präsentiert werden und für die Eingabe seiner Zugangsdaten stehen ihm verschiedene Möglichkeiten zur Auswahl (Tastatur, Fingerprint, Kamera, etc.)
In der folgenden Tabelle haben wir die unterschiedlichen App Typen und die empfohlenen OAuth2 Grant Types nochmals zusammengefasst.
App-Type | Recommended Grant-Type | Optional Grant Type |
---|---|---|
Backend-Service, M2M communication | Client-Credentials | |
Regular WebApps (PHP, ASP.NET) | PKCE | Authorization Code |
Single Page Applications, mobile Apps | PKCE | |
Apps for Smart-TV, Video-Console etc. | Device Code | PKCE, Authorization Code (beide nur, wenn Browser und irgendeine Art der Eingabe möglich ist) |
Unsere kurze Zusammenfassung über OAuth2, insbesondere der OAuth2 Grant Types und der Einordnung der Grant Types zu den unterschiedlichen Anwendungsfällen und Applikationstypen, soll bei der Entscheidung für den richten OAuth2 Grant unterstützen. Daher anbei noch ein kleines Entscheidungsdiagramm zur Übersicht.
Die Entscheidung ist gefallen und wir wissen jetzt, welcher Grant-Typ für unsere Anwendung der richtige ist. Aber für was stehen die Grant Typen überhaupt und wie funktionieren sie? Mit dieser Frage wollen wir uns in den nächsten Blogs beschäftigen.
Unser zweiter Blog der „take a auth-shot“ Reihe: take a auth-shot – Client Credentials Grant
Unser dritter Blog der „take a auth-shot“ Reihe: take a auth-shot – PKCE Grant