1. Einführung (Introduction)

Im traditionellen Client-Server-Authentifizierungsmodell fordert der Client eine zugriffsbeschränkte Ressource (geschützte Ressource) auf dem Server an, indem er sich beim Server mit den Anmeldeinformationen des Ressourcenbesitzers authentifiziert. Um Drittanbieteranwendungen Zugriff auf eingeschränkte Ressourcen zu geben, teilt der Ressourcenbesitzer seine Anmeldeinformationen mit dem Drittanbieter. Dies führt zu mehreren Problemen und Einschränkungen:

• Drittanbieteranwendungen müssen die Anmeldeinformationen des Ressourcenbesitzers für spätere Verwendung speichern, typischerweise ein Passwort im Klartext.
• Server müssen Passwortauthentifizierung unterstützen, trotz der Sicherheitsmängel, die Passwörtern innewohnen.
• Drittanbieteranwendungen erhalten zu weitreichenden Zugriff auf die geschützten Ressourcen des Ressourcenbesitzers, ohne dass dieser Dauer oder Umfang des Zugriffs auf eine begrenzte Teilmenge von Ressourcen beschränken kann.
• Ressourcenbesitzer können den Zugriff eines einzelnen Drittanbieters nicht widerrufen, ohne den Zugriff aller Drittanbieter zu widerrufen, und müssen dies durch Ändern des Passworts des Drittanbieters tun.
• Die Kompromittierung einer Drittanbieteranwendung führt zur Kompromittierung des Passworts des Endbenutzers und aller durch dieses Passwort geschützten Daten.

OAuth behebt diese Probleme durch Einführung einer Autorisierungsschicht und durch Trennung der Rolle des Clients von der Rolle des Ressourcenbesitzers. In OAuth fordert der Client Zugriff auf Ressourcen an, die vom Ressourcenbesitzer kontrolliert und vom Ressourcenserver gehostet werden, und erhält andere Anmeldeinformationen als die des Ressourcenbesitzers.

Statt die Anmeldeinformationen des Ressourcenbesitzers zum Zugriff auf geschützte Ressourcen zu verwenden, erhält der Client ein Zugangstoken -- eine Zeichenfolge, die einen bestimmten Geltungsbereich, eine Lebensdauer und weitere Zugriffseigenschaften bezeichnet. Zugangstokens werden Drittanbieter-Clients durch einen Autorisierungsserver mit Zustimmung des Ressourcenbesitzers ausgestellt. Der Client verwendet das Zugangstoken, um auf die vom Ressourcenserver gehosteten geschützten Ressourcen zuzugreifen.

Beispielsweise kann eine Endbenutzerin (Ressourcenbesitzerin) einem Druckdienst (Client) Zugriff auf ihre geschützten Fotos gewähren, die bei einem Fotodienst (Ressourcenserver) gespeichert sind, ohne ihren Benutzernamen und ihr Passwort mit dem Druckdienst zu teilen. Stattdessen authentifiziert sie sich direkt bei einem vom Fotodienst vertrauten Server (Autorisierungsserver), der dem Druckdienst delegationsspezifische Anmeldeinformationen (Zugangstoken) ausstellt.

Diese Spezifikation ist für die Verwendung mit HTTP ([RFC2616]) ausgelegt. Die Verwendung von OAuth über ein anderes Protokoll als HTTP liegt außerhalb des Umfangs dieser Spezifikation.

Das OAuth-1.0-Protokoll ([RFC5849]), das als Informationsdokument veröffentlicht wurde, war das Ergebnis einer kleinen Ad-hoc-Community. Diese Standards-Track-Spezifikation baut auf den Erfahrungen mit OAuth-1.0-Bereitstellungen sowie auf zusätzlichen Anwendungsfällen und Erweiterbarkeitsanforderungen aus der breiteren IETF-Community auf. OAuth 2.0 ist nicht rückwärtskompatibel mit OAuth 1.0. Beide Versionen können im Netz koexistieren, und Implementierungen können beide unterstützen. Ziel dieser Spezifikation ist jedoch, dass neue Implementierungen OAuth 2.0 gemäß diesem Dokument unterstützen und OAuth 1.0 nur zur Unterstützung bestehender Bereitstellungen verwendet wird. OAuth 2.0 teilt nur sehr wenige Implementierungsdetails mit OAuth 1.0. Implementierer, die mit OAuth 1.0 vertraut sind, sollten dieses Dokument ohne Annahmen über Struktur und Details lesen.

1.1. Rollen (Roles)

OAuth definiert vier Rollen:

Ressourcenbesitzer (Resource Owner)
Eine Entität, die Zugriff auf eine geschützte Ressource gewähren kann. Wenn der Ressourcenbesitzer eine Person ist, wird er als Endbenutzer bezeichnet.

Ressourcenserver (Resource Server)
Der Server, der die geschützten Ressourcen hostet und Anfragen für geschützte Ressourcen mit Zugangstokens akzeptieren und beantworten kann.

Client
Eine Anwendung, die im Namen des Ressourcenbesitzers und mit dessen Autorisierung Anfragen an geschützte Ressourcen stellt. Der Begriff "Client" impliziert keine bestimmten Implementierungsmerkmale, etwa ob die Anwendung auf einem Server, einem Desktop oder anderen Geräten ausgeführt wird.

Autorisierungsserver (Authorization Server)
Der Server, der dem Client Zugangstokens ausstellt, nachdem er den Ressourcenbesitzer erfolgreich authentifiziert und Autorisierung erhalten hat.

Die Interaktion zwischen Autorisierungsserver und Ressourcenserver liegt außerhalb des Umfangs dieser Spezifikation. Der Autorisierungsserver kann derselbe Server wie der Ressourcenserver oder eine separate Entität sein. Ein einzelner Autorisierungsserver kann Zugangstokens ausstellen, die von mehreren Ressourcenservern akzeptiert werden.

1.2. Protokollablauf (Protocol Flow)

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Abbildung 1: Abstrakter Protokollablauf

Der in Abbildung 1 dargestellte abstrakte OAuth-2.0-Ablauf beschreibt die Interaktion zwischen den vier Rollen:

(A) Der Client fordert Autorisierung vom Ressourcenbesitzer an. Die Autorisierungsanfrage kann direkt an den Ressourcenbesitzer gestellt werden, wie gezeigt, oder vorzugsweise indirekt über den Autorisierungsserver als Vermittler.

(B) Der Client erhält eine Autorisierung, also eine Anmeldeinformation, die die Autorisierung des Ressourcenbesitzers repräsentiert. Sie wird mit einem der vier in dieser Spezifikation definierten Grant-Typen oder mit einem Erweiterungs-Grant-Typ ausgedrückt. Der Grant-Typ hängt von der Methode ab, mit der der Client Autorisierung anfordert, und von den Typen, die der Autorisierungsserver unterstützt.

(C) Der Client fordert ein Zugangstoken an, indem er sich beim Autorisierungsserver authentifiziert und die Autorisierung vorlegt.

(D) Der Autorisierungsserver authentifiziert den Client und validiert die Autorisierung; falls sie gültig ist, stellt er ein Zugangstoken aus.

(E) Der Client fordert die geschützte Ressource vom Ressourcenserver an und authentifiziert sich durch Vorlegen des Zugangstokens.

(F) Der Ressourcenserver validiert das Zugangstoken und bedient die Anfrage, falls es gültig ist.

Die bevorzugte Methode, mit der der Client eine Autorisierung vom Ressourcenbesitzer erhält (Schritte (A) und (B)), verwendet den Autorisierungsserver als Vermittler, wie in Abbildung 3 in Abschnitt 4.1 dargestellt.

1.3. Autorisierung (Authorization Grant)

Eine Autorisierung ist eine Anmeldeinformation, die die Autorisierung des Ressourcenbesitzers zum Zugriff auf seine geschützten Ressourcen repräsentiert und vom Client verwendet wird, um ein Zugangstoken zu erhalten. Diese Spezifikation definiert vier Grant-Typen -- Autorisierungscode, implizit, Ressourcenbesitzer-Passwort-Anmeldeinformationen und Client-Anmeldeinformationen -- sowie einen Erweiterungsmechanismus für zusätzliche Typen.

1.3.1. Autorisierungscode (Authorization Code)

Der Autorisierungscode wird erhalten, indem ein Autorisierungsserver als Vermittler zwischen Client und Ressourcenbesitzer verwendet wird. Statt Autorisierung direkt beim Ressourcenbesitzer anzufordern, leitet der Client den Ressourcenbesitzer über dessen User-Agent gemäß [RFC2616] zu einem Autorisierungsserver, der den Ressourcenbesitzer anschließend mit dem Autorisierungscode zum Client zurückleitet.

Bevor der Autorisierungsserver den Ressourcenbesitzer mit dem Autorisierungscode zum Client zurückleitet, authentifiziert er den Ressourcenbesitzer und erhält Autorisierung. Da sich der Ressourcenbesitzer nur beim Autorisierungsserver authentifiziert, werden seine Anmeldeinformationen nie mit dem Client geteilt.

Der Autorisierungscode bietet wichtige Sicherheitsvorteile, etwa die Möglichkeit, den Client zu authentifizieren, sowie die direkte Übertragung des Zugangstokens an den Client, ohne es durch den User-Agent des Ressourcenbesitzers zu leiten und dadurch potenziell anderen Parteien, einschließlich des Ressourcenbesitzers, offenzulegen.

1.3.2. Implizit (Implicit)

Der implizite Grant ist ein vereinfachter Autorisierungscode-Ablauf, optimiert für Clients, die im Browser mit einer Skriptsprache wie JavaScript implementiert sind. Im impliziten Ablauf erhält der Client statt eines Autorisierungscodes direkt ein Zugangstoken als Ergebnis der Autorisierung durch den Ressourcenbesitzer. Der Grant-Typ ist implizit, weil keine Zwischenanmeldeinformation wie ein Autorisierungscode ausgestellt und später zum Erhalt eines Zugangstokens verwendet wird.

Beim Ausstellen eines Zugangstokens im impliziten Ablauf authentifiziert der Autorisierungsserver den Client nicht. In manchen Fällen kann die Clientidentität über die Weiterleitungs-URI verifiziert werden, mit der das Zugangstoken an den Client geliefert wird. Das Zugangstoken kann dem Ressourcenbesitzer oder anderen Anwendungen offengelegt werden, die Zugriff auf den User-Agent des Ressourcenbesitzers haben.

Implizite Grants verbessern die Reaktionsfähigkeit und Effizienz bestimmter Clients, etwa einer im Browser ausgeführten Anwendung, da weniger Roundtrips zum Erhalt eines Zugangstokens erforderlich sind. Dieser Vorteil muss jedoch gegen die Sicherheitsauswirkungen impliziter Grants abgewogen werden, etwa die in den Abschnitten 10.3 und 10.16 beschriebenen, insbesondere wenn der Autorisierungscode-Grant verfügbar ist.

1.3.3. Ressourcenbesitzer-Passwort-Anmeldeinformationen

Die Ressourcenbesitzer-Passwort-Anmeldeinformationen, also Benutzername und Passwort, können direkt als Autorisierung verwendet werden, um ein Zugangstoken zu erhalten. Sie sollten nur verwendet werden, wenn zwischen Ressourcenbesitzer und Client ein hohes Maß an Vertrauen besteht, etwa wenn der Client Teil des Betriebssystems des Geräts oder eine besonders privilegierte Anwendung ist, und wenn andere Grant-Typen wie der Autorisierungscode nicht verfügbar sind.

Obwohl dieser Grant-Typ direkten Clientzugriff auf die Anmeldeinformationen des Ressourcenbesitzers erfordert, werden diese Anmeldeinformationen nur für eine einzelne Anfrage verwendet und gegen ein Zugangstoken ausgetauscht. Der Grant-Typ kann vermeiden, dass der Client die Anmeldeinformationen des Ressourcenbesitzers für spätere Verwendung speichern muss, indem er sie gegen ein langlebiges Zugangstoken oder ein Aktualisierungstoken austauscht.

1.3.4. Client-Anmeldeinformationen (Client Credentials)

Client-Anmeldeinformationen oder andere Formen der Clientauthentifizierung können als Autorisierung verwendet werden, wenn der Autorisierungsumfang auf geschützte Ressourcen unter Kontrolle des Clients oder auf zuvor mit dem Autorisierungsserver vereinbarte geschützte Ressourcen beschränkt ist. Client-Anmeldeinformationen werden typischerweise verwendet, wenn der Client im eigenen Namen handelt, also zugleich Ressourcenbesitzer ist, oder wenn er Zugriff auf geschützte Ressourcen auf Grundlage einer zuvor mit dem Autorisierungsserver vereinbarten Autorisierung anfordert.

1.4. Zugangstoken (Access Token)

Zugangstokens sind Anmeldeinformationen zum Zugriff auf geschützte Ressourcen. Ein Zugangstoken ist eine Zeichenfolge, die eine dem Client ausgestellte Autorisierung repräsentiert. Die Zeichenfolge ist für den Client üblicherweise undurchsichtig. Tokens repräsentieren bestimmte Zugriffsumfänge und Zugriffsdauern, die vom Ressourcenbesitzer gewährt und vom Ressourcenserver und Autorisierungsserver durchgesetzt werden.

Das Token kann einen Bezeichner darstellen, mit dem Autorisierungsinformationen abgerufen werden, oder es kann die Autorisierungsinformationen in verifizierbarer Form selbst enthalten, etwa als Token-Zeichenfolge aus Daten und Signatur. Zusätzliche Authentifizierungsdaten, die außerhalb des Umfangs dieser Spezifikation liegen, können erforderlich sein, damit der Client ein Token verwenden kann.

Das Zugangstoken stellt eine Abstraktionsschicht bereit, die verschiedene Autorisierungskonstrukte wie Benutzername und Passwort durch ein einzelnes Token ersetzt, das der Ressourcenserver versteht. Dadurch können Zugangstokens restriktiver ausgestellt werden als die Autorisierung, mit der sie erlangt wurden, und der Ressourcenserver muss nicht viele verschiedene Authentifizierungsmethoden verstehen.

Zugangstokens können je nach Sicherheitsanforderungen des Ressourcenservers unterschiedliche Formate, Strukturen und Nutzungsverfahren haben, etwa kryptografische Eigenschaften. Attribute von Zugangstokens und Methoden zum Zugriff auf geschützte Ressourcen liegen außerhalb des Umfangs dieser Spezifikation und werden durch Begleitspezifikationen wie [RFC6750] definiert.

1.5. Aktualisierungstoken (Refresh Token)

Aktualisierungstokens sind Anmeldeinformationen zum Erhalt von Zugangstokens. Sie werden dem Client vom Autorisierungsserver ausgestellt und verwendet, um ein neues Zugangstoken zu erhalten, wenn das aktuelle Zugangstoken ungültig wird oder abläuft, oder um zusätzliche Zugangstokens mit identischem oder engerem Umfang zu erhalten. Zugangstokens können eine kürzere Lebensdauer und weniger Berechtigungen haben als vom Ressourcenbesitzer autorisiert. Die Ausstellung eines Aktualisierungstokens ist optional und liegt im Ermessen des Autorisierungsservers. Gibt der Autorisierungsserver ein Aktualisierungstoken aus, wird es bei der Ausstellung eines Zugangstokens einbezogen, also in Schritt (D) von Abbildung 1.

Ein Aktualisierungstoken ist eine Zeichenfolge, die die dem Client vom Ressourcenbesitzer gewährte Autorisierung repräsentiert. Die Zeichenfolge ist für den Client üblicherweise undurchsichtig. Das Token bezeichnet einen Bezeichner zum Abrufen der Autorisierungsinformationen. Anders als Zugangstokens sind Aktualisierungstokens nur zur Verwendung mit Autorisierungsservern bestimmt und werden nie an Ressourcenserver gesendet.

  +--------+                                           +---------------+
  |        |--(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        +---------------+

Abbildung 2: Aktualisieren eines abgelaufenen Zugangstokens

Der in Abbildung 2 dargestellte Ablauf umfasst:

(A) Der Client fordert ein Zugangstoken an, indem er sich beim Autorisierungsserver authentifiziert und eine Autorisierung vorlegt.

(B) Der Autorisierungsserver authentifiziert den Client und validiert die Autorisierung; falls sie gültig ist, stellt er ein Zugangstoken und ein Aktualisierungstoken aus.

(C) Der Client stellt beim Ressourcenserver eine Anfrage an eine geschützte Ressource, indem er das Zugangstoken vorlegt.

(D) Der Ressourcenserver validiert das Zugangstoken und bedient die Anfrage, falls es gültig ist.

(E) Die Schritte (C) und (D) wiederholen sich, bis das Zugangstoken abläuft. Wenn der Client weiß, dass das Zugangstoken abgelaufen ist, springt er zu Schritt (G); andernfalls stellt er eine weitere Anfrage an eine geschützte Ressource.

(F) Da das Zugangstoken ungültig ist, gibt der Ressourcenserver einen Fehler für ein ungültiges Token zurück.

(G) Der Client fordert ein neues Zugangstoken an, indem er sich beim Autorisierungsserver authentifiziert und das Aktualisierungstoken vorlegt. Die Anforderungen an die Clientauthentifizierung richten sich nach dem Clienttyp und den Richtlinien des Autorisierungsservers.

(H) Der Autorisierungsserver authentifiziert den Client und validiert das Aktualisierungstoken; falls es gültig ist, stellt er ein neues Zugangstoken und optional ein neues Aktualisierungstoken aus.

Die Schritte (C), (D), (E) und (F) liegen außerhalb des Umfangs dieser Spezifikation, wie in Abschnitt 7 beschrieben.

1.6. TLS-Version

Immer wenn diese Spezifikation Transport Layer Security (TLS) verwendet, wird sich die geeignete TLS-Version oder die geeigneten Versionen im Lauf der Zeit nach verbreiteter Bereitstellung und bekannten Sicherheitslücken richten. Zum Zeitpunkt der Erstellung ist TLS 1.2 [RFC5246] die neueste Version, besitzt jedoch eine sehr begrenzte Bereitstellungsbasis und ist möglicherweise nicht ohne Weiteres für Implementierungen verfügbar. TLS 1.0 [RFC2246] ist die am weitesten verbreitete Version und bietet die breiteste Interoperabilität.

Implementierungen können außerdem zusätzliche Sicherheitsmechanismen der Transportschicht unterstützen, die ihre Sicherheitsanforderungen erfüllen.

1.7. HTTP-Weiterleitungen

Diese Spezifikation verwendet HTTP-Weiterleitungen umfassend; dabei leitet der Client oder der Autorisierungsserver den User-Agent des Ressourcenbesitzers zu einem anderen Ziel. Obwohl die Beispiele in dieser Spezifikation den HTTP-Statuscode 302 verwenden, ist jede andere über den User-Agent verfügbare Methode zur Durchführung dieser Weiterleitung zulässig und gilt als Implementierungsdetail.

1.8. Interoperabilität

OAuth 2.0 stellt ein reichhaltiges Autorisierungsframework mit klar definierten Sicherheitseigenschaften bereit. Als reichhaltiges und hochgradig erweiterbares Framework mit vielen optionalen Komponenten wird diese Spezifikation für sich genommen jedoch wahrscheinlich eine große Bandbreite nicht interoperabler Implementierungen hervorbringen.

Außerdem lässt diese Spezifikation einige erforderliche Komponenten teilweise oder vollständig undefiniert, etwa Clientregistrierung, Fähigkeiten des Autorisierungsservers und Endpunkt-Ermittlung. Ohne diese Komponenten müssen Clients manuell und spezifisch für einen bestimmten Autorisierungsserver und Ressourcenserver konfiguriert werden, um interoperabel zu sein.

Dieses Framework wurde mit der klaren Erwartung entworfen, dass zukünftige Arbeiten präskriptive Profile und Erweiterungen definieren, die für vollständige Interoperabilität im Webmaßstab erforderlich sind.

1.9. Notationskonventionen

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in dieser Spezifikation sind wie in [RFC2119] beschrieben zu interpretieren.

Diese Spezifikation verwendet die Augmented-Backus-Naur-Form-(ABNF-)Notation aus [RFC5234]. Zusätzlich ist die Regel URI-reference aus "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] einbezogen.

Bestimmte sicherheitsbezogene Begriffe sind im Sinne von [RFC4949] zu verstehen. Dazu gehören unter anderem "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate" und "verify".

Sofern nicht anders angegeben, wird bei allen Protokollparameternamen und -werten zwischen Groß- und Kleinschreibung unterschieden.