7. Accès aux ressources protégées (Accessing Protected Resources)

Le client (Client) accède aux ressources protégées en présentant le jeton d'accès (Access Token) au serveur de ressources (Resource Server). Le serveur de ressources doit (MUST) valider le jeton d'accès et s'assurer qu'il n'a pas expiré et que sa portée (Scope) couvre la ressource demandée. Les méthodes utilisées par le serveur de ressources pour valider le jeton d'accès (ainsi que toutes les réponses d'erreur) dépassent le cadre de cette spécification, mais impliquent généralement une interaction ou une coordination entre le serveur de ressources et le serveur d'autorisation (Authorization Server).

La méthode par laquelle le client utilise le jeton d'accès pour s'authentifier auprès du serveur de ressources dépend du type de jeton d'accès émis par le serveur d'autorisation. En règle générale, cela implique l'utilisation du champ d'en-tête de requête HTTP « Authorization » [RFC2617] avec un schéma d'authentification défini par la spécification du type de jeton d'accès utilisé, tel que [RFC6750].

7.1. Types de jetons d'accès (Access Token Types)

Le type de jeton d'accès (Access Token Type) fournit au client les informations nécessaires pour utiliser avec succès le jeton d'accès pour effectuer une demande de ressource protégée (ainsi que les attributs spécifiques au type). Le client ne doit pas (MUST NOT) utiliser un jeton d'accès s'il ne comprend pas le type de jeton.

Par exemple, le type de jeton « bearer » défini dans [RFC6750] est utilisé en incluant simplement la chaîne de jeton d'accès dans la requête :

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Tandis que le type de jeton « mac » défini dans [OAuth-HTTP-MAC] est utilisé en émettant une clé de code d'authentification de message (Message Authentication Code, MAC) avec le jeton d'accès qui est utilisé pour signer certains composants des requêtes HTTP :

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
                   nonce="274312:dj83hs9s",
                   mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

Les exemples ci-dessus sont fournis à des fins d'illustration uniquement. Il est conseillé aux développeurs de consulter les spécifications [RFC6750] et [OAuth-HTTP-MAC] avant utilisation.

Chaque définition de type de jeton d'accès spécifie les attributs supplémentaires (le cas échéant) envoyés au client avec le paramètre de réponse « access_token ». Elle définit également la méthode d'authentification HTTP utilisée pour inclure le jeton d'accès lors de l'exécution d'une demande de ressource protégée.

7.2. Réponse d'erreur (Error Response)

Si une demande d'accès aux ressources échoue, le serveur de ressources devrait (SHOULD) informer le client de l'erreur. Bien que les détails de ces réponses d'erreur dépassent le cadre de cette spécification, ce document établit un registre commun dans la section 11.4 pour les valeurs d'erreur à partager entre les schémas d'authentification de jetons OAuth.

Les nouveaux schémas d'authentification conçus principalement pour l'authentification de jetons OAuth devraient (SHOULD) définir un mécanisme pour fournir un code d'état d'erreur au client, dans lequel les valeurs d'erreur autorisées sont enregistrées dans le registre d'erreurs établi par cette spécification.

Ces schémas peuvent (MAY) limiter l'ensemble des codes d'erreur valides à un sous-ensemble des valeurs enregistrées. Si le code d'erreur est renvoyé à l'aide d'un paramètre nommé, le nom du paramètre devrait (SHOULD) être « error ».

D'autres schémas capables d'être utilisés pour l'authentification de jetons OAuth, mais non principalement conçus à cette fin, peuvent (MAY) lier leurs valeurs d'erreur au registre de la même manière.

Les nouveaux schémas d'authentification peuvent (MAY) également choisir de spécifier l'utilisation des paramètres « error_description » et « error_uri » pour renvoyer des informations d'erreur d'une manière parallèle à leur utilisation dans cette spécification.

---