2.2. Access Token Request

Lorsque le paramètre resource est utilisé dans une requête de jeton d'accès adressée au point de terminaison de jeton, pour tous les types d'octroi, il indique le service cible ou la ressource protégée où le client entend utiliser le jeton d'accès demandé.

La ou les valeurs de ressource acceptables pour un serveur d'autorisation lorsqu'il satisfait une requête de jeton d'accès relèvent de sa seule discrétion selon la politique ou la configuration locale. Dans le cas d'une requête de type d'octroi refresh_token ou authorization_code, une telle politique peut limiter les ressources acceptables à celles initialement accordées par le propriétaire de ressource ou à un sous-ensemble de celles-ci. Dans le cas authorization_code où les ressources demandées sont un sous-ensemble de l'ensemble de ressources initialement accordées, le serveur d'autorisation émettra un jeton d'accès basé sur ce sous-ensemble de ressources demandées, tandis que tout jeton de rafraîchissement retourné reste lié à l'octroi original complet.

Lors de la demande d'un jeton, le client peut indiquer le ou les services cibles où il entend utiliser ce jeton via le paramètre resource et la portée souhaitée du jeton demandé via le paramètre scope. La sémantique d'une telle requête est que le client demande un jeton avec la portée demandée utilisable sur tous les services cibles demandés. En pratique, les droits d'accès demandés pour le jeton sont le produit cartésien de toutes les portées sur tous les services cibles. Dans la mesure du possible, lors de l'émission de jetons d'accès, le serveur d'autorisation devrait réduire la portée (downscope) associée à un jeton d'accès à la valeur que la ressource respective est capable de traiter et doit connaître. (Ici, « downscope » signifie accorder moins de permissions que celles initialement autorisées par le propriétaire de ressource.) Cela améliore encore la confidentialité car une liste de valeurs de portée indique que le propriétaire de ressource utilise les multiples services énumérés ; réduire un jeton à ce qui est nécessaire pour un service particulier peut limiter l'étendue de la divulgation de telles informations entre services différents. Comme spécifié à la section 5.1 de [RFC6749], le serveur d'autorisation doit indiquer la portée effective du jeton d'accès au client dans la valeur du paramètre de réponse scope lorsqu'elle diffère de la portée demandée par le client.

Suite à la requête d'autorisation en flux par code illustrée à la figure 2, les exemples ci-dessous montrent une requête de jeton d'accès de type d'octroi authorization_code (figure 3) et la réponse (figure 4) où le client indique au serveur d'autorisation qu'il souhaite le jeton d'accès pour utilisation à https://cal.example.com/ (sauts de ligne et indentation supplémentaires uniquement pour l'affichage).

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

Figure 3 : Requête de jeton d'accès

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"
}

Figure 4 : Réponse de jeton d'accès

Une requête de jeton d'accès ultérieure utilisant le jeton de rafraîchissement, où le client indique au serveur d'autorisation qu'il souhaite un jeton d'accès pour utilisation à https://contacts.example.com/, est illustrée à la figure 5 avec la réponse à la figure 6 (sauts de ligne et indentation supplémentaires uniquement pour l'affichage).

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

Figure 5 : Requête de jeton d'accès

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"
}

Figure 6 : Réponse de jeton d'accès

2.2. Access Token Request​

2.2. Access Token Request