© Excellent backgrounds/Shutterstock.com
Java Magazin
OAuth 2.0: Implicit Grant, Resource Owner Password Credentials Grant und Client Credentials Grant

Access granted!

Sie haben im ersten Teil der OAuth-2.0-Serie bereits die Grundlagen sowie den Authorization Code Grant kennengelernt. Wir betrachten nun im zweiten Teil - immer noch aus Sicht des Clients, also des API Users - die restlichen drei OAuth 2.0 Grants: den Implicit Grant, den Resource Owner Password Credentials Grant sowie den Client Credentials Grant.

Sven Haiges


Der Authorization Code Grant, den Sie in Teil 1 kennen gelernt haben, kann als der „klassische“ OAuth 2.0 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 Teil der Serie eignen sich jedoch für andere Clients: clientseitige Webapplikationen, mobile Clients sowie jegliche Clients, die auf eigene Ressourcen zugreifen wollen.

ArtikelserieTeil 1: Authorization Code GrantTeil 2: Weitere OAuth 2.0 GrantsTeil 3: Implementierung eines OAuth-2.0-Servers anhand des OAuth-2.0-Moduls von Spring Security

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 1 ist dieser Flow dargestellt. Gehen wir den Implicit Flow, der auch oft client-side Flow genannt wird, wieder Schritt für Schritt durch.

Abb. 1: ­OAuth 2.0 Flow...

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

Access granted!

Sie haben im ersten Teil der OAuth-2.0-Serie bereits die Grundlagen sowie den Authorization Code Grant kennengelernt. Wir betrachten nun im zweiten Teil - immer noch aus Sicht des Clients, also des API Users - die restlichen drei OAuth 2.0 Grants: den Implicit Grant, den Resource Owner Password Credentials Grant sowie den Client Credentials Grant.

Sven Haiges


Der Authorization Code Grant, den Sie in Teil 1 kennen gelernt haben, kann als der „klassische“ OAuth 2.0 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 Teil der Serie eignen sich jedoch für andere Clients: clientseitige Webapplikationen, mobile Clients sowie jegliche Clients, die auf eigene Ressourcen zugreifen wollen.

ArtikelserieTeil 1: Authorization Code GrantTeil 2: Weitere OAuth 2.0 GrantsTeil 3: Implementierung eines OAuth-2.0-Servers anhand des OAuth-2.0-Moduls von Spring Security

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 1 ist dieser Flow dargestellt. Gehen wir den Implicit Flow, der auch oft client-side Flow genannt wird, wieder Schritt für Schritt durch.

Abb. 1: ­OAuth 2.0 Flow...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang