2.1. Authorization Request

Lorsque le paramètre resource est utilisé dans une requête d'autorisation vers le point de terminaison d'autorisation, il indique l'identité de la ou des ressources protégées auxquelles l'accès est demandé. Lorsqu'un jeton d'accès sera retourné directement depuis le point de terminaison d'autorisation via le flux implicite (section 4.2 d'OAuth 2.0 [RFC6749]), la ressource demandée s'applique à ce jeton d'accès. Dans le flux par code (section 4.1 d'OAuth 2.0 [RFC6749]) où une représentation intermédiaire de l'octroi d'autorisation (le code d'autorisation) est retournée depuis le point de terminaison d'autorisation, la ressource demandée s'applique à l'octroi d'autorisation complet.

Pour une requête d'autorisation envoyée comme JSON Web Token (JWT), par exemple lors de l'utilisation du JWT Secured Authorization Request [JWT-SAR], une seule valeur du paramètre resource est représentée comme une chaîne JSON tandis que plusieurs valeurs sont représentées comme un tableau de chaînes.

Si le client omet le paramètre resource lors de la demande d'autorisation, le serveur d'autorisation PEUT traiter la requête sans ressource spécifique ou en utilisant une valeur de ressource par défaut prédéfinie. Alternativement, le serveur d'autorisation PEUT exiger que les clients spécifient la ou les ressources qu'ils entendent utiliser et PEUT faire échouer les requêtes qui omettent le paramètre avec une erreur invalid_target. Le serveur d'autorisation peut utiliser ces données pour informer l'utilisateur des ressources que le client va utiliser en son nom, pour appliquer une politique (par exemple refuser la requête en raison de ressources inconnues) et pour déterminer l'ensemble des ressources utilisables dans les requêtes de jeton d'accès ultérieures.

Si le serveur d'autorisation ne parvient pas à analyser la ou les valeurs fournies ou ne considère pas la ou les ressources comme acceptables, il devrait rejeter la requête avec une réponse d'erreur utilisant le code d'erreur invalid_target comme valeur du paramètre error et peut fournir des informations supplémentaires sur les raisons de l'erreur via error_description.

Un exemple de requête d'autorisation où le client indique au serveur d'autorisation qu'il souhaite un jeton d'accès pour utilisation à https://api.example.com/app/ est illustré à la figure 1 ci-dessous (sauts de ligne et indentation supplémentaires uniquement pour l'affichage).

GET /as/authorization.oauth2?response_type=token
   &client_id=example-client
   &state=XzZaJlcwYew1u0QBrRv_Gw
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
Host: authorization-server.example.com

Figure 1 : Requête d'autorisation en flux implicite

Ci-dessous, la figure 2 montre un exemple de requête d'autorisation utilisant le type de réponse code où le client demande l'accès aux contacts et au calendrier du propriétaire de ressource à https://cal.example.com/ et https://contacts.example.com/ (sauts de ligne et indentation supplémentaires uniquement pour l'affichage).

GET /as/authorization.oauth2?response_type=code
   &client_id=s6BhdRkqt3
   &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &scope=calendar%20contacts
   &resource=https%3A%2F%2Fcal.example.com%2F
   &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
Host: authorization-server.example.com

Figure 2 : Requête d'autorisation en flux par code

2.1. Authorization Request​

2.1. Authorization Request