Portabilité des tokens d’accès

Ce guide explique certains scénarios courants de portabilité. Vous pouvez ainsi opter pour la configuration d’application qui correspond le plus à vos besoins.

Utilisation de tokens avec différents types d’applications

Les tokens d’accès sont portables. Cela signifie que dès l’instant où vous obtenez un token, vous pouvez l’utiliser depuis n’importe quelle machine. Lorsque vous combinez des interfaces web, des clients mobiles et des serveurs, vous pouvez obtenir diverses configurations possibles. Toutefois, ces différentes configurations présentent divers inconvénients en termes de capacités et de sécurité.

Configuration	Avantages	Inconvénients	Remarques sur la sécurité
La connexion et les requêtes d’API se déroulent dans un client web (token de courte durée).	Facile à mettre en œuvre.	Aucune publication hors ligne. Aucun accès à long terme. Authentification fréquente obligatoire.
La connexion et les requêtes d’API se déroulent dans un client mobile natif ou un client web (token de longue durée).	Authentification moins fréquente.	Aucune publication hors ligne.
La connexion et les requêtes d’API se déroulent dans un client web (token de longue durée après échange de code).	Sécurité renforcée dans certaines situations.	Difficile à mettre en œuvre. Aucune publication hors ligne.	Utile uniquement dans certaines situations.
La connexion se déroule dans un client mobile natif ou un client web. Les requêtes d’API se déroulent dans un serveur (avec un token de longue durée).	Publication hors ligne. Fonctionnalités de sécurité supplémentaires avec les appels basés sur le serveur.	Appels du serveur obligatoires pour transmettre les appels par proxy.	Utiliser `appsecret_proof` pour tous les appels.
La connexion se déroule dans un client mobile natif ou un client web. Les requêtes d’API se déroulent dans un serveur ou dans le client.	Publication hors ligne. Publication réalisée par l’utilisateur à partir du client.	Difficile à mettre en œuvre.	Utiliser `appsecret_proof` pour tous les appels effectués depuis le serveur.

Connexion et requêtes d’API dans un client web ou natif

Il s’agit du modèle le plus simple : l’authentification et les requêtes d’API sont effectuées dans le client. Ce modèle compte trois configurations possibles :

Le client web ou natif procède à l’authentification et utilise le token de courte ou de longue durée renvoyé pour effectuer des appels.
Le client web procède à l’authentification et remplace le token de courte durée par un token de longue durée à l’aide d’un serveur. Ce token est renvoyé au client web et ce dernier effectue des appels d’API à l’aide du token de longue durée.
Le client web procède à l’authentification et remplace le token de courte durée par un token de longue durée à l’aide d’un serveur. Ce serveur envoie un code au client. Le client remplace ce code par un token de longue durée et l’utilise pour effectuer des appels d’API. Cette configuration est rarement utilisée.

Flux avec le client web ou natif

Flux du client web avec un token de longue durée

Flux du client web avec remplacement du code

Connexion avec le client et appels d’API avec le serveur

Dans cette configuration courante, le client se charge de l’authentification, mais tous les appels d’API sont effectués par le serveur à la place du client. Le serveur peut utiliser le paramètre appsecret_proof pour renforcer la sécurité lorsqu’il passe des appels.

Connexion avec le client et appels d’API avec le serveur ou le client

Cette configuration combine les approches décrites ci-dessus.

Configuration des tokens d’accès avec les SDK

Vous pouvez indiquer le token d’accès à utiliser en effectuant un appel d’API dans nos SDK. Plusieurs options s’offrent à vous :

La méthode setCurrentAccessToken du SDK Facebook pour Android utilise le paramètre accessToken.
La méthode setCurrentAccessToken du SDK Facebook pour iOS utilise le paramètre token.
La méthode FB.api() du SDK Facebook pour JavaScript utilise le paramètre access_token.