3. Protokoll-Endpunkte (Protocol Endpoints)
Der Autorisierungsprozess verwendet zwei Autorisierungsserver-Endpunkte (HTTP-Endpunkte):
- Autorisierungs-Endpunkt (Authorization Endpoint) - Wird vom Client verwendet, um die Autorisierung vom Ressourcenbesitzer über eine Umleitung des Benutzeragenten zu erhalten.
- Token-Endpunkt (Token Endpoint) - Wird vom Client verwendet, um eine Autorisierung (Authorization Grant) oder ein Aktualisierungstoken (Refresh Token) gegen ein Zugangstoken (Access Token) auszutauschen.
Zusätzlich gibt es einen Client-Endpunkt (Client Endpoint):
- Weiterleitungs-Endpunkt (Redirection Endpoint) - Wird vom Autorisierungsserver verwendet, um Antworten mit Autorisierungsinformationen über den Benutzeragenten des Ressourcenbesitzers an den Client zurückzugeben.
Nicht alle Endpunkte werden in allen OAuth-Autorisierungsflüssen verwendet. Beispielsweise verwendet der implizite Fluss (Implicit Grant) keinen Token-Endpunkt, während der Ressourcenbesitzer-Passwort-Anmeldeinformationen-Fluss (Resource Owner Password Credentials Grant) keinen Autorisierungs-Endpunkt verwendet.
Endpunkt-URIs können (MAY) eine Abfragekomponente (<RFC3986> Abschnitt 3) enthalten, dürfen (MUST NOT) jedoch keine Fragmentkomponente enthalten. Der Autorisierungsserver und der Client müssen (MUST) zusätzliche Parameter zu URIs hinzufügen, die die von dieser Spezifikation definierten Parameter enthalten, indem sie die Abfragekomponente oder das application/x-www-form-urlencoded-Format verwenden. Die Weiterleitungs-URI ist jedoch von dieser Anforderung ausgenommen.
3.1. Autorisierungs-Endpunkt (Authorization Endpoint)
Der Autorisierungs-Endpunkt (Authorization Endpoint) wird verwendet, um mit dem Ressourcenbesitzer zu interagieren und die Autorisierung zu erhalten. Der Autorisierungsserver muss (MUST) zuerst die Identität des Ressourcenbesitzers überprüfen. Die Art und Weise, wie der Autorisierungsserver den Ressourcenbesitzer authentifiziert (z. B. Benutzername und Passwort, Sitzungscookie), liegt außerhalb des Umfangs dieser Spezifikation.
Die Mittel, durch die der Client die Autorisierung vom Ressourcenbesitzer erhält (über Umleitung oder direkt), müssen gemäß den Fähigkeiten, Anforderungen und Sicherheitsüberlegungen des Autorisierungsservers bestimmt werden. Bei Verwendung eines umleitungsbasierten Flusses fungiert der Autorisierungsserver als Vermittler zwischen dem Client und dem Ressourcenbesitzer über den Benutzeragenten (normalerweise einen Webbrowser).
Bei der Kommunikation mit dem Autorisierungs-Endpunkt über HTTP-Umleitung muss (MUST) der Autorisierungsserver die Verwendung von TLS erfordern. Die Endpunkt-URI muss (MUST) eine absolute URI sein, wie in <RFC2616> definiert. Die Endpunkt-URI darf (MUST NOT) eine Fragmentkomponente enthalten.
Da der Autorisierungs-Endpunkt keine Client-Authentifizierung erfordert, kann er anfällig für bestimmte Sicherheitslücken sein, wie z. B.:
- Der Ressourcenbesitzer kann den Client nicht authentifizieren und kann von einem böswilligen Client getäuscht werden.
- Der Ressourcenbesitzer kann den Autorisierungsserver nicht authentifizieren und kann von einem böswilligen Autorisierungsserver getäuscht werden.
Um diese Bedrohungen zu mindern, sollte (SHOULD) der Autorisierungsserver dem Ressourcenbesitzer ermöglichen, die Identität des Clients zu überprüfen (siehe Abschnitt 10.12) und TLS verwenden, um die Authentizität des Endpunkts des Autorisierungsservers zu garantieren (siehe Abschnitte 1.6 und 10.9).
3.1.1. Antworttyp (Response Type)
Der Autorisierungs-Endpunkt (Authorization Endpoint) wird verwendet, um mehrere Antworttypen zu unterstützen, die durch den Anforderungsparameter response_type bestimmt werden. Der Wert des response_type-Parameters ist eine durch Leerzeichen getrennte, Groß-/Kleinschreibung beachtende Liste, die nur ASCII-Zeichen [USASCII] verwendet.
Erweiterungsantworttypen können (MAY) zusätzliche Werte enthalten. Wenn der response_type-Parameter einen nicht erkannten Wert enthält oder ein Wert fehlt, muss (MUST) der Autorisierungsserver eine Fehlerantwort zurückgeben, wie in Abschnitt 4.1.2.1 beschrieben.
3.1.2. Weiterleitungs-Endpunkt (Redirection Endpoint)
Nachdem er seine Interaktion mit dem Ressourcenbesitzer abgeschlossen hat, leitet der Autorisierungsserver den Benutzeragenten des Ressourcenbesitzers zurück zum Client. Der Autorisierungsserver leitet den Benutzeragenten des Ressourcenbesitzers zur registrierten Weiterleitungs-URI (Redirection URI) des Clients um.
Die Weiterleitungs-Endpunkt-URI muss (MUST) die folgenden Anforderungen erfüllen:
- Sie muss (MUST) eine absolute URI sein, wie in
<RFC3986>Abschnitt 4.3 definiert. - Die Weiterleitungs-URI darf (MUST NOT) eine Fragmentkomponente enthalten.
Vertraulichkeit von Endpunktanfragen
Der Weiterleitungs-Endpunkt (Redirection Endpoint) sollte (SHOULD) die Verwendung von TLS erfordern, wenn die angeforderten oder ausgetauschten Informationen sensibel oder wertvoll sind. Client-Anmeldeinformationen und Zugangstokens können in der Antwort bei der Umleitung enthalten sein, daher wird die Verwendung von TLS empfohlen (siehe Abschnitte 1.6 und 10.9).
Registrierungsanforderungen
Der Autorisierungsserver muss (MUST) die Registrierung der Weiterleitungs-URI erfordern für:
- Öffentliche Clients (Public Client)
- Vertrauliche Clients (Confidential Client), die den impliziten Autorisierungstyp (Implicit Grant Type) verwenden
Der Autorisierungsserver sollte (SHOULD) die Registrierung der Weiterleitungs-URI für alle Clients erfordern.
Der Autorisierungsserver sollte (SHOULD) dem Client erlauben, mehrere Weiterleitungs-URIs zu registrieren. Gehen Sie nicht davon aus, dass ein Teil der registrierten Weiterleitungs-URIs nicht übereinstimmt.
Wenn die Registrierung der Weiterleitungs-URI erforderlich ist, sollte (SHOULD) der Autorisierungsserver die Registrierung von teilweisen Weiterleitungs-URIs zulassen. In diesem Fall muss (MUST) der Autorisierungsserver die vom Client bereitgestellte vollständige Weiterleitungs-URI bei jeder Anfrage validieren (siehe Abschnitt 3.1.2.3).
Dynamische Konfiguration
Wenn keine Weiterleitungs-URI registriert ist, muss (MUST) der Client eine Weiterleitungs-URI in jeder Autorisierungsanforderung einschließen (unter Verwendung des redirect_uri-Parameters).
Wenn eine Weiterleitungs-URI registriert ist und keine Weiterleitungs-URI in der Autorisierungsanforderung enthalten ist, muss (MUST) der Autorisierungsserver die registrierte Weiterleitungs-URI verwenden.
Wenn eine Weiterleitungs-URI in der Autorisierungsanforderung enthalten ist, muss (MUST) der Autorisierungsserver überprüfen, dass der angeforderte Wert mit mindestens einer der registrierten Weiterleitungs-URIs übereinstimmt.
Ungültiger Endpunkt
Wenn während der Validierung der Weiterleitungs-URI ein Fehler auftritt, muss (MUST) der Autorisierungsserver den Ressourcenbesitzer informieren und darf (MUST NOT) automatisch zur ungültigen Weiterleitungs-URI umleiten.
Endpunktinhalt
Die Umleitungsanforderung kann sensible Informationen wie den Autorisierungscode (Authorization Code) oder das Zugangstoken (Access Token) enthalten, daher sollte (SHOULD) der Client sicherstellen, dass der Weiterleitungs-Endpunkt keine Informationen an Dritte (außer dem Ressourcenbesitzer) weitergibt.
3.2. Token-Endpunkt (Token Endpoint)
Der Token-Endpunkt (Token Endpoint) wird vom Client verwendet, um ein Zugangstoken (Access Token) zu erhalten, indem er eine Autorisierung (Authorization Grant) oder ein Aktualisierungstoken (Refresh Token) vorlegt. Der Token-Endpunkt wird mit allen Autorisierungstypen außer dem impliziten Autorisierungstyp (Implicit Grant Type) verwendet (bei dem ein Zugangstoken direkt vom Autorisierungs-Endpunkt ausgegeben wird).
Der Standort des Token-Endpunkts und die Art des Zugriffs darauf werden normalerweise in der Dienstdokumentation beschrieben. Die Endpunkt-URI kann (MAY) eine Abfragekomponente (<RFC3986> Abschnitt 3) enthalten, darf (MUST NOT) jedoch zusätzliche Parameter enthalten. Die Endpunkt-URI darf (MUST NOT) eine Fragmentkomponente enthalten.
Der Token-Endpunkt muss (MUST) die Verwendung von TLS erfordern. Der Client muss (MUST) die HTTP-POST-Methode verwenden, um Anfragen an den Token-Endpunkt zu stellen.
Parameter, die in Anfragen an den Token-Endpunkt enthalten sind, müssen (MUST) im HTTP-Anforderungsentitätskörper gesendet werden und müssen (MUST) das application/x-www-form-urlencoded-Format verwenden.
3.2.1. Client-Authentifizierung (Client Authentication)
Vertrauliche Clients (Confidential Client) oder andere Clients, die Client-Anmeldeinformationen erhalten haben, müssen (MUST) sich beim Autorisierungsserver am Token-Endpunkt authentifizieren. Die Client-Authentifizierung wird für folgende Zwecke verwendet:
- Bestätigung der Identität des Clients (nur basierend auf der Client-Kennung). Dies ist wichtig, um zu verhindern, dass vertrauliche Clients einen nicht autorisierten Autorisierungscode gegen ein Zugangstoken austauschen. Wenn die Übertragung des Autorisierungscodes über einen unsicheren Kanal erfolgt oder wenn der Autorisierungsserver nicht bestätigen kann, dass der Client den Autorisierungscode erhalten hat, muss (MUST) der Autorisierungsserver die Client-Authentifizierung erzwingen.
- Bindung von Aktualisierungstokens (Refresh Token) an den Client. Wenn das Aktualisierungstoken an den Client gebunden ist, verhindert die Client-Authentifizierung, dass ein anderer Client ein kompromittiertes Aktualisierungstoken missbraucht.
- Ermöglichen, dass der Client seine Client-Anmeldeinformationen rotieren kann.
Der Client darf (MUST NOT) mehr als eine Authentifizierungsmethode in jeder Anfrage verwenden. Öffentliche Clients (Public Client) (Clients ohne Client-Anmeldeinformationen) müssen (MUST) die Client-Kennung in Anfragen einschließen, die an den Token-Endpunkt gesendet werden.
3.3. Zugangstokenbereich (Access Token Scope)
Die Autorisierungs- und Token-Endpunkte ermöglichen es dem Client, den Bereich (Scope) der Zugriffsanforderung unter Verwendung des Anforderungsparameters scope anzugeben. Der Autorisierungsserver informiert dann den Client über den Bereich des ausgegebenen Zugangstokens unter Verwendung des Antwortparameters scope.
Der Wert des scope-Parameters wird als durch Leerzeichen getrennte, Groß-/Kleinschreibung beachtende Liste von Bereichswerten ausgedrückt. Die Definition von Bereichswerten liegt beim Autorisierungsserver. Wenn Bereichswerte definiert sind, muss (MUST) der Autorisierungsserver sowohl die vom Client angeforderten Bereiche als auch die tatsächlich gewährten Bereiche dokumentieren.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
Der Autorisierungsserver kann (MAY) die unterstützten Bereichswerte vollständig dokumentieren. Der Autorisierungsserver kann (MAY) einen Teil, alle oder keinen der vom Client angeforderten Bereiche teilweise genehmigen, ablehnen oder ignorieren. Wenn die Anforderung den scope-Parameter nicht enthält oder dieser leer ist, muss (MUST) der Autorisierungsserver die Autorisierungsanforderung ablehnen, einen Standardbereich anwenden oder den vom Client angeforderten Bereich ignorieren. Der Autorisierungsserver darf (MUST NOT) mit einem leeren Bereich antworten.