2.2. Access Token Request (Zugriffstoken-Anfrage)

Wird der Parameter resource in einer an den Token-Endpunkt gerichteten Zugriffstoken-Anfrage verwendet, gilt er für alle Gewährungstypen (grant types) und gibt den Zieldienst oder die geschützte Ressource an, in der der Client das angeforderte Zugriffstoken einsetzen will.

Die für einen Autorisierungsserver bei der Erfüllung einer Zugriffstoken-Anfrage akzeptablen Ressourcenwerte liegen allein in seinem Ermessen auf Grundlage lokaler Richtlinie oder Konfiguration. Bei einer Anfrage vom Gewährungstyp refresh_token oder authorization_code kann eine solche Richtlinie akzeptable Ressourcen auf die vom Ressourceninhaber ursprünglich gewährten oder eine Teilmenge davon beschränken. Im Fall authorization_code, wenn die angeforderten Ressourcen eine Teilmenge der ursprünglich gewährten Ressourcenmenge sind, gibt der Autorisierungsserver ein Zugriffstoken auf Basis dieser Teilmenge aus, während ein zurückgegebenes Aktualisierungstoken an die vollständige ursprüngliche Gewährung gebunden bleibt.

Bei der Token-Anfrage kann der Client die gewünschte(n) Zieldienst(e) über den Parameter resource und den gewünschten Scope des angeforderten Tokens über scope angeben. Die Semantik einer solchen Anfrage ist, dass der Client ein Token mit dem angeforderten Scope anfordert, das an allen angeforderten Zieldiensten verwendbar ist. Effektiv sind die angeforderten Zugriffsrechte des Tokens das kartesische Produkt aller Scopes an allen Zieldiensten. Soweit möglich SOLLTE der Autorisierungsserver beim Ausgeben von Zugriffstoken den mit einem Zugriffstoken verknüpften Scope-Wert auf den Wert verkleinern (downscope), den die jeweilige Ressource verarbeiten kann und kennen muss. („Downscope“ bedeutet hier: weniger Berechtigungen als ursprünglich vom Ressourceninhaber autorisiert.) Dies verbessert den Datenschutz weiter, da eine Liste von Scope-Werten darauf hindeutet, dass der Ressourceninhaber die aufgeführten verschiedenen Dienste nutzt; die Verkleinerung eines Tokens auf das für einen bestimmten Dienst Nötige kann das Ausmaß begrenzen, in dem solche Informationen über verschiedene Dienste hinweg offenbar werden. Wie in Abschnitt 5.1 von [RFC6749] spezifiziert, MUSS der Autorisierungsserver den effektiven Scope des Zugriffstokens dem Client im Wert des Antwortparameters scope mitteilen, wenn er sich vom vom Client angeforderten Scope unterscheidet.

Anschließend an die in Abbildung 2 gezeigte Autorisierungsanfrage im Code-Flow zeigen die folgenden Beispiele eine Zugriffstoken-Anfrage vom Gewährungstyp authorization_code (Abbildung 3) und die Antwort (Abbildung 4), in der der Client dem Autorisierungsserver mitteilt, dass er das Zugriffstoken für die Nutzung unter https://cal.example.com/ wünscht (zusätzliche Zeilenumbrüche und Einrückung nur zu Anzeigezwecken).

POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
&resource=https%3A%2F%2Fcal.example.com%2F

Abbildung 3: Zugriffstoken-Anfrage

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
    JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
    iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs
    ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK
    lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf
    zkiQNVpYw",
   "token_type":"Bearer",
   "expires_in":3600,
   "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
   "scope":"calendar"
}

Abbildung 4: Zugriffstoken-Antwort

Eine nachfolgende Zugriffstoken-Anfrage unter Verwendung des Aktualisierungstokens, in der der Client dem Autorisierungsserver mitteilt, dass er ein Zugriffstoken für die Nutzung unter https://contacts.example.com/ wünscht, ist in Abbildung 5 gezeigt, die Antwort in Abbildung 6 (zusätzliche Zeilenumbrüche und Einrückung nur zu Anzeigezwecken).

POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2
&resource=https%3A%2F%2Fcontacts.example.com%2F

Abbildung 5: Zugriffstoken-Anfrage

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
    JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
    iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
    ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
    OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
    UowfmtNaA5EikYAw",
   "token_type":"Bearer",
   "expires_in":3600,
   "scope":"contacts"
}

Abbildung 6: Zugriffstoken-Antwort

2.2. Access Token Request (Zugriffstoken-Anfrage)​

2.2. Access Token Request (Zugriffstoken-Anfrage)