© DrHitch/Shutterstock.com
OAuth 2.0

2 OAuth 2.0: Implicit Grant, Resource Owner Password Credentials Grant und Client Credentials Grant


Sie haben im ersten Kapitel dieses shortcuts bereits die Grundlagen sowie den Authorization Code Grant kennengelernt. Wir betrachten nun im zweiten Kapitel – immer noch aus Sicht des Clients, also des API Users – die restlichen drei OAuth2 Grants: den Implicit Grant, den Resource Owner Password Credentials Grant sowie den Client Credentials Grant.

Der Authorization Code Grant aus Kapitel 1 kann als der „klassische“ OAuth2 Grant angesehen werden. Die meisten öffentlichen APIs wie die von Facebook, Google, Pinterest oder auch Foursquare unterstützen ihn. Der User wird dabei per Redirect zum Authorization Server Endpoint geschickt, muss sich dort einloggen und dann den Client autorisieren. Es erfolgt die Rückgabe eines Authorization Codes per erneutem Redirect, die der Client in einem zweiten Request zum Token Endpoint in ein Access Token eintauscht. Dieser Flow eignet sich sehr gut für serverseitige Webapplikationen. Die Grants in diesem Kapitel des E-Books eignen sich jedoch für andere Clients: clientseitige Webapplikationen, mobile Clients sowie jegliche Clients, die auf eigene Ressourcen zugreifen wollen.

Implicit Grant

Der Implicit Grant Flow ist dem Authorization Code Flow recht ähnlich – zumindest aus Sicht des Anwenders. Letzterer wird zunächst per Redirect zum Authorization Endpoint des Providers geschickt, muss sich dort authentifizieren (Login) und den Client autorisieren und wird dann per erneutem Redirect zurück zu der Webapplikation des Clients geschickt. Es gibt jedoch wichtige Unterschiede:

  • Der Implicit Grant Flow unterstützt keine Client Authentication, d. h. es gibt kein client_id- und client_secret-Paar, mit dem sich der Client ausweisen kann. Das liegt daran, dass dieser Flow vor allem für browserbasierte Szenarien entwickelt worden ist, und in Ressourcen des Browsers kann man schlecht Geheimnisse verbergen (das HTML Markup oder JavaScript-Ressourcen können einfach eingesehen werden).
  • Dieser Flow unterstützt ebenso – aufgrund der geringeren Sicherheit – keine Refresh Tokens. Der Zugriff, der damit dem Client gewährt wird, ist also immer nur von temporärer Dauer.
  • Das Access Token wird nicht durch einen erneuten Request zum Token Endpoint erlangt, sondern direkt im Hash (#) dem Redirect URL übergeben. Somit steht das Token beispielsweise JavaScript-Clients zur Verfügung, die auf den Hash des URL zugreifen können. Serverseitige Logik kann jedoch nicht auf den Hash zugreifen, da dieser nicht mit an den Server geschickt wird.

In Abbildung 2.1 ist dieser Flow dargestellt. Gehen wir den Implicit Flow, der auch oft client-side Flow genannt wird, wieder Schritt für Schritt durch.

Abbildung2_1.png

Abbildung 2.1: OAuth2 Flow mit dem Implicit Grant. Quelle: OAuth2 Spec [1]

Der Flow beginnt (A), indem der User-Agent des Anwenders zum Authorization Endpoint umgeleitet wird. Der Client Identifier, der bei der Registrierung dem Entwickler bekannt gegeben wurde, sowie der Redirection URI sind die wichtigsten Parameter:

  • response_type: Um den Implicit Flow zu benutzen, muss dieser Parameter mit token belegt werden. Damit wir dem Authorization Endpoint mitgeteilt, dass der Implicit Grant benutzt werden soll und das Access Token im Falle des Erfolges direkt an den Redirect URI im Hash (#) angehängt wird.
  • client_id: Diese identifiziert wieder den Client. Tatsache ist, dass diese ID jedem frei zugänglich ist, da sie im JavaScript oder sonstigen Ressourcen, auf die der Browser zugreifen kann, gespeichert ist. Aus diesem Grund gibt es kein client_secret, da dieses genauso zugänglich wäre und damit keinen Sinn macht.
  • redirect_uri: Nach erfolgreicher Autorisierung leitet der Authorization Endpoint den User-Agent des Anwenders zu diesem Redirect URI um und hängt das Access Token im Hash (#) an. Da dieser URI bei der Registrierung des Clients angegeben worden ist, kann somit eine gewisse Sicherheit erreicht werden.
  • scope: Erneut können die Bereiche angegeben werden, auf die der Client Zugriff erhalten soll.
  • state: Zum Schutz vor CSRF-Attacken sollte ein zufällig erzeugter Wert angegeben und später verglichen werden.

In Groovy-Code sieht diese lange Liste erneut viel netter aus (Listing 2.1). Hier ist der Code eines Gaelyk Controllers, der den initialen Redirect zum Authorization Endpoint auslöst.

import java.net.URLEncoder

def client_id = 'client-side'
def redirect_uri = 'https://<my_server>/oauth2_implicit_callback'

def scopes = [
'customer'
]

def state = new Random(System.currentTimeMillis()).nextInt().toString()
session.state = state

redirect "https://<server>/oauth/authorize?client_id=${client_id}&redirect_uri=${URLEncoder.encode(redirect_uri, 'UTF-8')}&response_type=token&scope=${URLEncoder.encode(scopes.join(' '), 'UTF-8')}&state=${URLEncoder.encode(state, 'UTF-8')}"

Listing 2.1

Der Code unterscheidet sich marginal von dem für den Authorization Code Flow. Der response_type-Parameter ist nun token, und es fehlt auch das client_secret, da unser C...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang