Envoi d’une requête à une ressource protégée
Il y a trois méthodes pour l’envoi d’une requête à une ressource protégée : une bonne, une acceptable et une mauvaise :
Ce qui suit est en partie traduit de la RFC 6750, section 2
2. Requêtes authentifiées
Cette section définit trois méthodes d’envoi de jetons d’accès aux serveurs de ressources. Les clients NE DOIVENT PAS utiliser plus d’une méthode pour transmettre le jeton dans chaque requête.
2.1. Demande d’autorisation par Champ d’en-tête (la bonne méthode)
Lors de l’envoi du jeton d’accès par l’en-tête de la requête (Request Header) dans le champ "Authorization" défini par HTTP / 1.1 [RFC2617], le client utilise le schéma d’authentification "Bearer" pour transmettre le jeton d’accès.
Par exemple :
GET / resource HTTP / 1.1
Host: oa.dnc.global
Authorization: Bearer mF_9.B5f-4.1JqMExemples de code :
PHP
- . $access_token));
SPIP
- $url = "https://oa.dnc.global/userinfo";
- 'methode' => 'GET',
- 'datas' => 'Authorization: Bearer ' . $access_token,
- );
- $res = recuperer_url($url, $options);
Les clients DOIVENT faire des requêtes authentifiées avec un jeton Bearer en utilisant le champ d’en-tête de demande « Authorization » avec le schéma d’autorisation du protocole HTTP « Bearer ». Les serveurs de ressources DOIVENT supporter cette méthode.
2.2. Paramètres form-urlencoded dans le corps (une méthode acceptable sous conditions)
Lors de l’envoi du jeton d’accès dans le corps d’entité de requête HTTP, le Client ajoute le jeton d’accès au corps de requête en Paramètre "access_token". Le client NE DOIT PAS utiliser cette méthode à moins que toutes les conditions suivantes ne soient remplies :
L’entête d’entité de requête HTTP inclut le champ d’en-tête "Content-Type" "application / x-www-form-urlencoded".
Le corps de l’entité suit les exigences d’encodage du type de contenu "Application / x-www-form-urlencoded" tel que défini par HTML 4.01 [W3C.REC-html401-19991224].
Le corps de l’entité de demande HTTP est mono-partie.
Le contenu codé dans le corps de l’entité DOIT se composer entièrement de caractères ASCII [USASCII].
La méthode de requête HTTP suit la sémantique définie pour le corps de requête. En particulier, cela signifie que la méthode "GET" NE DOIT PAS être utilisée.
Le corps de l’entité PEUT inclure d’autres paramètres spécifiques aux requêtes, auquel cas le paramètre "access_token" DOIT être correctement séparé des paramètres spécifiques à la requête en utilisant le caractère "&" (ASCII Code 38).
Par exemple, le client effectue la requête HTTP suivante en utilisant la sécurité des couches de transport :
POST / ressource HTTP / 1.1
Host: oa.dnc.global
Content-Type: application/ x-www-form-urlencoded
access_token = mF_9.B5f-4.1JqMLa méthode "application/ x-www-form-urlencoded" NE DOIT PAS être utilisée sauf dans les contextes d’application où les navigateurs participants n’ont pas accès au champ d’en-tête de demande "Authorization". Les serveurs PEUVENT soutenir cette méthode.
Exemple de code :
PHP
- 'access_token' => $access_token,
- );
2.3. Paramètres de requête dans l’URI (la mauvaise méthode)
Lors de l’envoi du jeton d’accès dans l’URI de requête HTTP, le client ajoute le jeton d’accès au composant de requête de l’URI tel que défini par "Uniform Resource Identifier (URI) : Syntaxe générique" [RFC3986], en utilisant le paramètre "access_token".
Par exemple, le client effectue la requête HTTP suivante en utilisant la sécurité des couches de transport :
GET /resource?access_token=mF_9.B5f-4.1JqM HTTP / 1.1
Host: oa.dnc.global...
Les clients utilisant la méthode URI Query Parameter DEVRAIENT également envoyer un entête Cache-Control contenant l’option "no-store". Les réponses de succès (status 2XX) du serveur à ces demandes Serveur DOIVENT contenir un entête Cache-Control avec l’option "private".
En raison des faiblesses de sécurité associées à la méthode URI (Voir la section 5), y compris la forte probabilité que l’URL contenant le jeton d’accès soit enregistrée, elle NE DOIT PAS être utilisée à moins qu’il soit impossible de transporter le jeton d’accès dans le champ d’en-tête de requête "Authorization" ou dans le corps d’entité de la requête HTTP. Les serveurs de ressources PEUVENT supporter cette méthode.
Cette méthode est incluse pour documenter une utilisation possible ; son utilisation n’est pas recommandée en raison de ses déficiences en matière de sécurité (voir section 5), mais également parce qu’elle utilise un nom de paramètre de requête réservé, ce qui est contraire aux meilleures pratiques de l’espace de noms URI, définies par « Architecture of the World Wide Web, Volume One" [W3C.REC-webarch-20041215].
Voir aussi :
Validation du jeton d’accès par interrogation du point d’extrémité "resource"
Contrôle d’accès HTTP (CORS)
Recommandation de sécurité
Les ressources protégées qui reçoivent un jeton doivent toujours le vérifier. Elles devraient le faire par Introspection, et devraient toujours transmettre le paramètre ’requester_ip’ pour éviter de répondre à un malware.
RSS 2.0