OAuth

19. Jänner 2021
Azure

Bei OAuth sind normalerweise 4 Parteien relevant:

Authorization Server: Dieser wird auch „Identity Provider“ genannt und ist dafür zuständig, die Identität eines Benutzers zu gewährleisten, Rechte auf Ressourcen zu gewähren oder zu verbieten und Tokens auszustellen.

Resource Owner: Dies ist normalerweise der Endbenutzer, der Clients Zugriff auf bestimmte Ressourcen gewährt.

OAuth Client: Dies ist die App, identifiziert über eine App-ID. Über diese gewährt der Resource Owner das Abfragen von Tokens beim Authorization Server.

Resource Server: Hier liegen Daten und Ressourcen. Er vertraut dem Authorization Server und verwendete die Tokens zu Verifizierung, ob Zugriff auf bestimmte Ressourcen erlaubt ist.

Auth Code Grant

Dieser Flow wird primär von Anwendungen verwendet, die auf einem Gerät installiert sind. Die Anwendung arbeitet im Auftrag des Resource Owners – daher greifen in Azure die „Delegated permissions“. Der Ablauf ist wie folgt:

  1. OAuth Client öffnet eine URL oder ein Popup des Authorization Servers, bei der ein Authorization Code angefordert wird (dabei gibt der Benutzer dem OAuth Client die gewünschten Rechte), der dem OAuth Client gesendet wird.
  2. OAuth Client fordert eine Access-Token an und übermittelt Authorization Code, Client-ID, … Hierbei wird neben dem Access-Token meist auch ein Refresh-Token übermittelt, mit dem ein neuer Access-Token angefordert werden kann, wenn dieser abgelaufen ist.
  3. Mit dem Access-Token können anschließend Anfragen an den Resource Server gestellt werden.

Client Credentials Grant

Hierbei wird nicht die Identität eines Benutzers wie bei „Auth Code Grant“ verwendet, sondern die App ist selbst eine Identität (bspw. bei einem Hintergrundprozess). In Azure greifen daher die „Application permissions“. Dabei werden keine Access-Tokens verwendet, die gespeichert und erneuert werden müssen.

  1. OAuth Client öffnet eine URL oder ein Popup des Authorization Servers, wo der Admin die Berechtigung für den OAuth Client bestätigt.
  2. Der OAuth Client bekommt als Ergebnis die Tenant-ID zurück.
  3. Der OAuth Client fordert mit seinen Client-ID + Secret direkt einen Access-Token an.
  4. Mit diesem und der Tenant-ID können nur Anfragen an den Resource Server gestellt werden.