OAuth 2.0

OAuth 2.0 ist ein Autorisierungsrahmenwerk, das es Anwendungen ermöglicht, im Namen eines Benutzers sicher auf Ressourcen zuzugreifen. Es ermöglicht die Delegation von Zugriffen, ohne dass Benutzer ihre Passwörter an Drittanbieteranwendungen weitergeben müssen. OAuth 2.0 wird häufig für die Integration von Webanwendungen und mobilen Apps verwendet, um auf APIs zuzugreifen.

Hauptkomponenten

Resource Owner (Benutzer): Die Entität, die Zugriff auf eine Ressource hat.
Client (Anwendung): Die Anwendung, die Zugriff auf die Ressource anfordert.
Authorization Server: Der Server, der das OAuth 2.0 Protokoll implementiert und Access Tokens ausgibt.
Resource Server: Der Server, der die geschützten Ressourcen beherbergt und das Access Token überprüft.

Grundprinzip

OAuth 2.0 trennt die Rolle des Ressourceneigentümers von der Rolle des Clients. Anstatt dass der Benutzer sein Passwort dem Client gibt, gibt der Benutzer ein Autorisierungs-Token, das der Client verwenden kann, um im Namen des Benutzers auf Ressourcen zuzugreifen.

Autorisierungs-Flows

OAuth 2.0 unterstützt mehrere Autorisierungs-Flows, die für verschiedene Anwendungsszenarien optimiert sind. Die zwei häufigsten sind der Authorization Code Flow und der Implicit Flow.

Authorization Code Flow

Dieser Flow wird hauptsächlich von Server-seitigen Anwendungen verwendet, die sicher mit dem Authorization Server kommunizieren können.

Schritte:

Authorization Request: Der Benutzer wird zur Autorisierungsseite des Authorization Servers weitergeleitet.

GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&state=STATE

2. Authorization Grant: Der Benutzer stimmt dem Zugriff zu und wird zur Anwendung zurückgeleitet, wobei ein Autorisierungscode an die Weiterleitungs-URI angehängt wird.

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=AUTH_CODE&state=STATE

3. Access Token Request: Die Anwendung tauscht den Autorisierungscode gegen ein Access Token ein.

POST /token
Authorization: Basic BASE64(CLIENT_ID:CLIENT_SECRET)
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTH_CODE&redirect_uri=REDIRECT_URI

4. Access Token Response: Der Authorization Server gibt ein Access Token und optional ein Refresh Token zurück.

{
  "access_token": "ACCESS_TOKEN",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "REFRESH_TOKEN",
  "scope": "read write"
}

Implicit Flow

Dieser Flow wird hauptsächlich von browserbasierten Anwendungen verwendet, bei denen der Client nicht sicher ist.

Schritte:

Authorization Request: Der Benutzer wird zur Autorisierungsseite des Authorization Servers weitergeleitet.

GET /authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&state=STATE

2. Access Token: Der Benutzer stimmt dem Zugriff zu und wird zur Anwendung zurückgeleitet, wobei das Access Token an die Weiterleitungs-URI angehängt wird.

HTTP/1.1 302 Found
Location: https://client.example.com/cb#access_token=ACCESS_TOKEN&token_type=bearer&expires_in=3600&state=STATE

Beispiel

Ein Entwickler möchte, dass seine Anwendung auf die E-Mail-Kontakte eines Benutzers zugreift. Anstatt das Passwort des Benutzers zu speichern, nutzt die Anwendung OAuth 2.0, um ein Access Token zu erhalten und damit auf die Kontakte zuzugreifen.

Beispiel-Ablauf:

Die Anwendung leitet den Benutzer zu Google weiter, um sich anzumelden und der Anwendung Zugriff zu gewähren.
Nach der Zustimmung leitet Google den Benutzer mit einem Autorisierungscode zur Anwendung zurück.
Die Anwendung tauscht den Autorisierungscode gegen ein Access Token bei Google ein.
Mit dem Access Token kann die Anwendung nun sicher auf die E-Mail-Kontakte des Benutzers zugreifen.