OAuth2 und OpenID Connect für APIs
OAuth2 ermöglicht autorisierten Zugriff auf APIs, OpenID Connect ergänzt darauf eine standardisierte Möglichkeit zur Nutzerauthentifizierung.
Kompakte Beschreibung
OAuth2 ist ein weit verbreitetes Autorisierungsframework, das es Anwendungen erlaubt, im Namen eines Nutzers auf Ressourcen zuzugreifen, ohne das Passwort direkt zu erhalten. OpenID Connect ist eine darauf aufbauende Identitätsschicht, die mit ID Tokens die Authentifizierung eines Nutzers bestätigt. Zusammen bilden sie das Fundament für modernes Single Sign-On und API-Sicherheit. Wichtige Konzepte sind Authorization Server, Resource Server, Client, Access Token, ID Token, Scopes, Refresh Token und verschiedene Flows wie Authorization Code Flow mit PKCE. Eine korrekte Umsetzung ist entscheidend, um Token-Diebstahl, Man-in-the-Middle-Angriffe und unbefugten Zugriff zu verhindern. OAuth2 und OpenID Connect werden heute in fast allen modernen Web-, Mobile- und Cloud-Anwendungen eingesetzt.
Wichtige Komponenten
Authorization Server
Der Authorization Server ist die zentrale Stelle, die Token ausstellt. Er authentifiziert den Nutzer, fragt die Zustimmung ein und gibt Access Token und optional ID Token sowie Refresh Token aus. Bekannte Authorization Server sind Keycloak, Auth0, Okta und Azure AD.
Resource Server
Der Resource Server ist die API, die geschützte Ressourcen bereitstellt. Er validiert das Access Token und entscheidet anhand von Scopes und Claims, ob die Anfrage erlaubt ist. Der Resource Server kennt den Nutzer nicht direkt, sondern nur die Informationen im Token.
Client
Der Client ist die Anwendung, die im Namen des Nutzers auf die API zugreifen möchte. Clients können vertraulich, wie ein Backend-Server, oder öffentlich, wie eine Mobile App oder Single-Page-Application, sein. Öffentliche Clients benötigen besondere Schutzmaßnahmen wie PKCE.
Access Token
Das Access Token ist ein kurzlebiges Token, das dem Client den Zugriff auf geschützte Ressourcen erlaubt. Es wird im Authorization Header als Bearer Token übertragen. Access Tokens sollten nie länger als nötig gültig sein und immer über HTTPS übertragen werden.
ID Token
Das ID Token wird von OpenID Connect ausgestellt und enthält Informationen zur Identität des Nutzers, wie Sub, Name und E-Mail. Es ist ein JWT und wird für Authentifizierung genutzt, nicht für den API-Zugriff. API-Zugriff erfolgt mit dem Access Token.
Refresh Token
Refresh Tokens sind langlebige Token, mit denen ein Client ein neues Access Token anfordern kann, ohne den Nutzer erneut nach seinem Passwort zu fragen. Sie müssen besonders geschützt werden und sollten bei Verdacht auf Kompromittierung widerrufbar sein.
Scopes
Scopes definieren, welche Berechtigungen ein Client anfragt. Beispiele sind read, write oder profile. Der Nutzer oder der Authorization Server entscheidet, welche Scopes gewährt werden. Der Resource Server prüft dann, ob die angefragte Aktion im Scope des Tokens liegt.
Authorization Code Flow
Der Authorization Code Flow ist der sicherste und gängigste OAuth2 Flow. Der Nutzer wird zum Authorization Server weitergeleitet, meldet sich an und der Server leitet einen Code an die Client-Applikation zurück. Der Client tauscht den Code gegen Access Token und ID Token ein.
PKCE
PKCE steht für Proof Key for Code Exchange und ist eine Erweiterung des Authorization Code Flows. Er schützt öffentliche Clients wie Mobile Apps oder Single-Page-Applications gegen Code-Interception-Angriffe. Der Client erzeugt einen zufälligen Code Verifier und sendet einen Hash davon als Code Challenge.
Client Credentials Flow
Der Client Credentials Flow wird für maschinen-zu-maschine Kommunikation verwendet, wenn kein Nutzer involviert ist. Der Client authentifiziert sich mit Client ID und Client Secret direkt beim Authorization Server und erhält ein Access Token.
Implicit Flow und Password Flow
Der Implicit Flow und der Resource Owner Password Credentials Flow gelten als veraltet und sollten nicht mehr verwendet werden, weil sie Sicherheitsrisiken bergen. Moderne Anwendungen setzen stattdessen auf Authorization Code Flow mit PKCE.
Token-Validierung
Der Resource Server muss das Access Token validieren, bevor er eine Anfrage bearbeitet. Dazu prüft er Signatur, Ablaufzeit, Aussteller, Audience und Scopes. Selbst signierte JWTs werden mit dem öffentlichen Schlüssel des Authorization Servers geprüft, opaque Tokens durch Introspection.
Logout und Session Management
OpenID Connect definiert verschiedene Logout-Mechanismen, darunter RP-Initiated Logout, Back-Channel Logout und Front-Channel Logout. Sie ermöglichen es, Sitzungen zentral zu beenden und Tokens zu invalidieren.
Praxisbeispiel
Eine Mobile App möchte auf eine Benutzerprofil-API zugreifen. Sie nutzt den Authorization Code Flow mit PKCE.
Schritt 1: Die App erzeugt einen Code Verifier und eine Code Challenge:
code_verifier = random_string(128)
code_challenge = BASE64URL(SHA256(code_verifier))Schritt 2: Die App leitet den Nutzer zum Authorization Server:
https://auth.example.com/authorize?
response_type=code
&client_id=mobile-app
&redirect_uri=app://callback
&scope=openid profile read:profile
&code_challenge=abc123
&code_challenge_method=S256
&state=xyz789Schritt 3: Nach erfolgreicher Anmeldung und Zustimmung erhält die App einen Authorization Code:
app://callback?code=AUTH_CODE&state=xyz789Schritt 4: Die App tauscht den Code gegen Tokens ein:
POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=AUTH_CODE
&redirect_uri=app://callback
&client_id=mobile-app
&code_verifier=CODE_VERIFIERSchritt 5: Die App ruft die API auf:
GET /api/v1/profile
Authorization: Bearer ACCESS_TOKENDurch PKCE ist der Flow auch für öffentliche Clients sicher, weil ein abgefangener Code ohne den Code Verifier nicht eingetauscht werden kann.
FAQ: OAuth2 und OpenID Connect
1. Was ist OAuth2?
2. Was ist OpenID Connect?
3. Was ist der Unterschied zwischen Access Token und ID Token?
4. Was ist PKCE?
5. Was sind Scopes?
6. Was ist ein Refresh Token?
7. Was ist der Authorization Code Flow?
8. Was ist der Client Credentials Flow?
9. Warum gelten Implicit und Password Flow als veraltet?
10. Was ist Token Introspection?
11. Was ist ein Audience Claim?
12. Wie wird ein JWT Access Token validiert?
13. Was ist Single Sign-On?
14. Was ist Back-Channel Logout?
15. Was sind typische Fehler bei OAuth2?
Quellen
- https://datatracker.ietf.org/doc/html/rfc6749
- https://openid.net/specs/openid-connect-core-1_0.html
- https://datatracker.ietf.org/doc/html/rfc7636
Buchempfehlungen zur API-Sicherheit
Wenn Du Dich weiter mit OAuth2, OpenID Connect und API-Sicherheit beschäftigen möchtest, empfehlen wir Dir die folgenden Bücher:
Keine Bücher für Kategorie "security" gefunden.