Passer au contenu principal

OAuth Echo

OAuth Echo est un moyen de déléguer en toute sécurité l’autorisation OAuth à un tiers lors d’une interaction avec une API. Quatre parties sont impliquées dans cette interaction :
  • l’Utilisateur, qui utilise X via une App X spécifique et autorisée
  • le Consommateur, c’est-à-dire l’App X qui tente d’interagir avec le fournisseur de médias tiers (par exemple, un site de partage de photos)
  • le Délégateur, c’est-à-dire le fournisseur de médias tiers
  • le Fournisseur de services, alias X lui-même  
En substance, préparez une requête que le Délégateur enverra à la X API au nom d’une application et d’un utilisateur. Placez ce qui serait autrement une requête OAuth signée dans un en-tête HTTP et demandez au Délégateur d’envoyer cette requête à X après avoir effectué l’opération intermédiaire. Voici un exemple : l’Utilisateur veut téléverser une photo. Le Consommateur va appeler la méthode d’envoi du Délégateur avec un POST. Le POST doit contenir l’image, mais aussi deux éléments supplémentaires sous forme d’en-têtes HTTP :
  • x-auth-service-provider — en pratique, c’est le domaine vers lequel doit être envoyée la délégation d’identité — dans le cas de X, définissez-le sur https://api.x.com/1.1/account/verify_credentials.json. Les intégrations X basées sur iOS5 ajouteront un paramètre supplémentaire application_id à cette URL, qui sera également utilisé pour calculer l’oauth_signature utilisée dans x-verify-credentials-authorization.
  • x-verify-credentials-authorization — le Consommateur doit créer tous les paramètres OAuth nécessaires pour pouvoir appeler https://api.x.com/1.1/account/verify_credentials.json en utilisant OAuth dans l’en-tête HTTP (par exemple, cela devrait ressembler à OAuth oauth_consumer_key=”…”, oauth_token=”…”, oauth_signature_method=”…”, oauth_signature=”…”, oauth_timestamp=”…”, oauth_nonce=”…”, oauth_version=”…”).  
Gardez à l’esprit que l’ensemble de la transaction doit s’effectuer pendant la période où le oauth_timestamp est encore valide. Autrement, au lieu d’envoyer ces deux paramètres dans l’en-tête, ils peuvent être envoyés dans le POST sous forme de x_auth_service_provider et x_verify_credentials_authorization — dans ce cas, n’oubliez pas d’échapper les paramètres et de les inclure dans la chaîne de base de la signature OAuth — comme pour l’encodage des paramètres dans toute requête. Il est préférable d’utiliser des en-têtes HTTP afin de garder les opérations aussi distinctes que possible. L’objectif du Délégateur, à ce stade, est de vérifier que l’Utilisateur est bien celui qu’il prétend être avant d’enregistrer le média. Une fois que le Délégateur a reçu toutes les informations ci-dessus via sa méthode d’envoi, il doit stocker temporairement l’image, puis construire un appel vers l’endpoint spécifié dans l’en-tête x-auth-service-provider — dans ce cas, https://api.x.com/1.1/account/verify_credentials.json — en utilisant le même en-tête d’authentification OAuth fourni par le Consommateur dans l’en-tête x-verify-credentials-authorization.  

Bonnes pratiques pour OAuth Echo

Utilisez l’URL fournie par x-auth-service-provider pour effectuer la requête, et non une valeur codée en dur. Apple iOS, par exemple, ajoute un paramètre supplémentaire application_id à toutes les requêtes OAuth, et sa présence doit être conservée à chaque étape d’OAuth Echo. Pour la partie autorisation OAuth, prenez la valeur de l’en-tête x-verify-credentials-authorization et placez-la dans un en-tête Authorization distinct pour l’appel au fournisseur de services. Par précaution, vérifiez également que la valeur de x-auth-service-provider est correcte.
  • Si le fournisseur de services renvoie un HTTP 200, parfait. Le délégant doit stocker l’image de manière permanente, générer une URL et la retourner.
  • Si le fournisseur de services ne renvoie pas un HTTP 200, supprimez l’image, puis retournez une erreur au consommateur.
I