OAuth2, kurz für „Open Authorization“, ist ein offenes Standardprotokoll, welches zur Clientauthorizierung bei APIs entwickelt wurde. Ziel ist es Client-Anwendungen einen begrenzten Zugang auf WebService und Ressourcen zu erteilen.
Das Verfahren ist in den RFC 5849 aus dem Jahr 2012 spezifiziert.
In dem klassischen Client Server Authentifizierungsmodell (z. B. Basic Authentification) fragt der Client die Ressource unter Verwendung der Zugangsdaten die am Server hinterlegt sind an. Dies bedingt, dass die Zugangsdaten in der Client-Anwendung bekannt sein müssen. Weiterhin ist die Einschränkung der verwendeten Client-Anwendung nicht gegeben. Durch die Verwendung eines speziellen Autorisierungs-layers, der von der eigentlichen Anfrage des Services oder der Ressource getrennt ist, und getrennten Rollen in oAuth2 werden diese Einschränkungen aufgehoben.
Rollen in oAuth2
OAuth2 unterscheidet vier Rollen / Beteiligte:
Resource Owner: Ein Unternehmen, das einem Client Zugriff auf seine geschützten Daten gewährt.
Resource Server: Ein Server, auf dem die geschützten Daten des Resource Owners bereitgestellt werden.
Client: Eine Desktop-, Web- oder Mobile-Anwendung, die auf die geschützten Daten des Resource Owners zugreifen will.
Authorization Server: Ein Server, der den Resource Owner authentifiziert und einen zeitlich begrenzten Access-Token für einen von ihm definierten Anwendungsbereich (scope) ausstellt. Authorization Server und Resource Server werden in der Praxis häufig zusammen betrieben und dann auch als OAuth-Server bezeichnet.
Berechtigungstypen (Grand Types) in oAuth2
Um den unterschiedlichen Anwendungsfällen den Autorisierungsprozess zu ermöglichen wird in oAuth2 in folgende Berechtigungstypen unterschieden:
Autorisierungscode (Authorization Code):
Der Typ kommt zum Einsatz, wenn die Zugangsdaten der Client-Anwendung nicht bekannt sein sollen. Die Übertragung der Zugangsdaten erfolgt nicht aus der Client-Anwendung, sondern werden in einer Eingabemaske die vom Authentifizierungsserver bereitgestellten Daten eingegeben.Implizite Autorisierung (Implicit Authorization):
Der Typ ähnelt der Basis Authentifizierung. Es werden nur die Zugangsdaten des Benutzer verwendet.Passwortfreigabe durch den Resource Owner(Resource Owner Password Credentials):
Der Typ kommt zum Einsatz, wenn neben den Zugangsdaten des Benutzers auch die Berechtigung der Client-Anwendung geprüft werden soll.Client-Berechtigung(Client Credentials):
Dieser besonders simple Genehmigungsprozess kommt dann zum Einsatz, wenn dem Client unabhängig von Benutzerdaten Zugriff auf Daten erteilt werden soll.
Da in der der Kommunikation zwischen Handwerkssoftware und Großhandel sowohl die Authentifizierung des Benutzers als auch die Einschränkung der verwendeten Client-Anwendung relevant ist, wird der Berechtigungstyp “Passwortfreigabe durch den Resource Owner(Resource Owner Password Credentials)” verwendet.
Grundsätzlicher Kommunikationsablauf
Das folgende Schaubild stellt den grundsätzlichen Ablauf von oAuth2 dar:
| Code Block | ||
|---|---|---|
| ||
+--------+ +---------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | | Authorization | | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +---------------+ |
Folgende Schritte sind im Schaubild enthalten:
A: Anfrage der Berechtigung wird am Authentifizierungsserver gestellt.
B: Bereitstellen der zeitbegrenzten “Access Token” und “Refresh Token” durch den Authentifizierungsserver.
C: Anfrage des Services oder der Ressource unter Verwendung des “Access Token”.
D: Der Server prüft die Berechtigung und stellt die angefragte Ressource zur Verfügung.
E: Die Schritte C und D können wiederholt werden, solange das “Access Token” gültig ist.
F: Im Fall, dass das “Access Token” abgelaufen ist, wird eine entsprechende Fehlermeldung bereitgestellt.
G: Mittels des “Refresh Token” wird ohne erneute Authentifizierung ein neues “Access Token” am Authentifizierungsserver angefragt.
H: Der Authentifizierungsserver prüft das “Refresh Token” und stellt ein neues “Access Token” bereit.
Kommunikationsablauf Berechtigungstyp “Passwortfreigabe durch den Resource Owner”
Das folgende Schaubild stellt den Ablauf der Anfrage des “Access Token” am Authentifizierungsserver im Kontext des Berechtigungstyps “Passwortfreigabe durch den Resource Owner“ dar.
| Code Block | ||
|---|---|---|
| ||
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+ |
Folgende Schritte sind im Schaubild enthalten:
A: Zugangsdaten des Benutzers werden der Client-Anwendung zur Verfügung gestellt.
B: Anfrage der Berechtigung unter Verwendung der Zugangsdaten des Benutzers und der Identifikation der Client-Anwendung am Authentifizierungsserver.
B: Bereitstellen der zeitbegrenzten “Access Token” und “Refresh Token” durch den Authentifizierungsserver
Die weiteren Schritte zur Anfrage des Services bzw. der Ressource sowie die erneute Anfrage eines “Access Token” unter Verwendung des “Refresh Token” erfolgt analog den Schritten C - H im Schaubild “Grundsätzlicher Kommunikationsablauf“.