Facebook Login

Demander et révoquer des autorisations

Chaque type de processus de connexion possède sa propre méthode de demande d’autorisations, selon votre plateforme et la façon dont vous choisissez d’intégrer Facebook Login :

Web

Applications mobiles

Notez qu’il est possible d’utiliser plusieurs des API mentionnées ci-dessus pour demander des autorisations supplémentaires tout au long de la durée de vie d’une application, et pas seulement lors de la première connexion.

Optimisation des demandes d’autorisations

En règle générale, les utilisateurs d’une application auxquels de nombreuses autorisations sont demandées préfèrent ne pas passer par Facebook pour se connecter. Précisément, nos études montrent que les applications demandant plus de quatre autorisations enregistrent une baisse considérable du nombre de personnes qui terminent le processus de connexion.

Règles

Vous trouverez ci-dessous quelques règles à suivre lorsque vous demandez des autorisations pendant et après le processus de connexion :

  • Demandez uniquement les autorisations indispensables au bon fonctionnement d’une application.

  • Demandez des autorisations en contexte. Par exemple, si votre application souhaite montrer des lieux d’intérêt à proximité du domicile d’un utilisateur, demander l’autorisation user_location avant d’afficher ces informations aide l’utilisateur à mieux comprendre la raison pour laquelle on lui demande cette autorisation.

  • Séparez les demandes d’autorisation de lecture des demandes d’autorisation de publication. Pour en savoir plus, consultez la section ci-dessous.

  • Ne demandez jamais des autorisations qui pourraient vous être utiles plus tard. Les utilisateurs se méfieront et pourraient décider de ne pas utiliser votre application.

  • Avant de demander une autorisation aux utilisateurs, expliquez-leur pourquoi vous la demandez. Ainsi, vous augmentez les chances qu’ils acceptent de vous donner l’accès aux informations dont vous avez besoin.

Autorisations de publication

Les applications doivent séparer les demandes d’autorisation de lecture des demandes d’autorisation de publication. Configurez votre application afin qu’elle demande uniquement les autorisations de lecture les plus importantes lors de la connexion initiale, puis les autorisations de publication au moment où un utilisateur en a réellement besoin (par exemple, lorsqu’il souhaite créer une actualité Open Graph depuis l’application). Vous offrez ainsi une expérience d’utilisation de qualité et optimisez les conversions.

Il se peut que vous receviez des alertes développeur si votre application demande successivement des autorisations de lecture et de publication. Si vous ne souhaitez plus recevoir ces alertes, séparez vos demandes ou suivez les recommandations ci-dessous concernant les cas exceptionnels.

Dans les rares cas où votre application demande directement des autorisations de publication (par exemple, une application qui se contente de publier l’humeur d’une personne sur Facebook), ne demandez que les autorisations de lecture minimales lors de la connexion initiale. Une fois l’utilisateur connecté, présentez-lui un écran expliquant les raisons pour lesquelles votre application a besoin d’autorisations de publication et invitez-le à accepter la demande d’autorisation de publication en cliquant sur un bouton. L’utilisateur dispose ainsi de plus de contexte et est plus susceptible de se connecter.

Il arrive que vous deviez demander des autorisations de lecture et d’écriture successivement, par exemple, la première fois que vous associez un compte créé à l’aide d’une adresse e-mail au compte Facebook d’un utilisateur. Ce cas de figure survient généralement lorsqu’un utilisateur souhaite partager une actualité sur son journal Facebook. Lorsque votre application crée la boîte de dialogue Login, l’utilisateur voit apparaître deux boîtes de dialogue en même temps. La première l’invite à associer son compte à votre application, tandis que la seconde sert à demander des autorisations de publication. Dans ce cas, veillez à ne demander que des autorisations de lecture de type public_profile. Vous offrez ainsi une expérience d’utilisation de qualité, étant donné que l’utilisateur souhaite publier du contenu à partir de votre application, sans nécessairement accorder des autorisations de lecture supplémentaires. Par ailleurs, vous améliorez également votre taux de conversion.

Vérification des autorisations actuelles

Facebook laisse les utilisateurs libres de choisir les autorisations qu’ils accordent à une application. Ce contrôle va au-delà de la boîte de dialogue Login. Ils peuvent choisir de ne pas accorder certaines autorisations au cours du processus de connexion. Ils peuvent également retirer des autorisations à tout moment, à partir des paramètres de confidentialité de Facebook. Lorsqu’une autorisation est nécessaire, l’application doit vérifier la validité de cette autorisation avant d’essayer de passer un appel d’API. Par exemple, l’application doit vérifier qu’elle bénéficie toujours de l’autorisation email avant d’envoyer un message.

Pour les applications web, nous fournissons un point de terminaison de l’API Graph pour récupérer une liste des autorisations accordées :

GET /{user-id}/permissions

L’appel doit être passé à l’aide d’un token d’accès utilisateur ou du token d’accès de votre application. L’appel renvoie alors une chaîne au format JSON, qui contient les noms des autorisations ayant été accordées à l’application ainsi que leur état :

{
  "data": [
    {
      "permission": "public_profile",
      "status": "granted"
    },
    {
      "permission": "email",
      "status": "granted"
    },
    {
      "permission": "user_friends",
      "status": "declined"
    }
  ]
}

Nous proposons également des méthodes dans les SDK pour iOS et Android, qui fournissent à la plateforme utilisée des représentations adaptées des autorisations accordées à votre application.

Gestion des autorisations manquantes

Lorsqu’une application demande des autorisations, les utilisateurs peuvent toutes les refuser, en accorder certaines ou les modifier à une date ultérieure. Les applications doivent être en mesure de gérer ces situations afin de garantir une expérience d’utilisation optimale.

Tout d’abord, elles doivent être capables de gérer des autorisations demandées, mais pas accordées :

  • Vérifiez les autorisations accordées avant d’essayer d’utiliser les API qui en ont besoin.
  • Détectez les erreurs d’autorisation renvoyées lorsqu’une demande d’API est demandée sans l’autorisation adéquate. Voici un exemple d’erreur :
{
  "error": {
    "message": "(#200) The user hasn't authorized the application
     to perform this action",
    "type": "OAuthException",
    "code": 200
  }
}

Dès qu’une application a détecté qu’un utilisateur a refusé toutes les autorisations ou certaines d’entre elles, elle peut réintroduire une seule fois une demande pour chaque autorisation refusée dans le processus de connexion. Néanmoins, cette pratique n’est pas agréable pour l’utilisateur et doit être évitée autant que possible. Si un utilisateur indique très clairement ne pas vouloir accorder à une application une autorisation en particulier, il est peu probable qu’il change d’avis, même en lui soumettant à nouveau la demande d’autorisation. Optez plutôt pour les solutions suivantes :

  • Si un utilisateur ignore la boîte de dialogue Login, expliquez-lui clairement les raisons pour lesquelles vous demandez chaque autorisation. Ensuite, donnez-lui la possibilité de cliquer ou d’appuyer sur un bouton pour revenir à la boîte de dialogue de demandes d’autorisations. Assurez-vous de ne jamais rediriger les gens immédiatement vers une boîte de dialogue de demandes d’autorisations sans leur avoir fourni une explication au préalable.

  • Si un utilisateur a refusé d’accorder une autorisation à votre application, la boîte de dialogue Login empêchera votre application de réintroduire une demande d’autorisation, à moins que votre demande ne contienne auth_type=rerequest.

  • Si un utilisateur a accordé certaines autorisations et en a refusé d’autres, réintroduisez une demande pour les autorisations manquantes au moment où votre application en a besoin. Par exemple, si votre application envoie les confirmations de commande à l’adresse e-mail de vos utilisateurs, vous ne devez leur demander leur e-mail (autorisation email) qu’au moment où ils effectuent une commande.

  • Si les autorisations que vous demandez dans la boîte de dialogue Login ne sont pas indispensables au bon fonctionnement de votre application et de ses fonctionnalités, permettez qu’elle soit utilisée sans autorisation.

Il se peut que vous receviez des alertes développeur si votre application redirige plusieurs fois des utilisateurs ayant refusé des autorisations vers des boîtes de dialogue d’autorisations. Suivez ces règles si vous ne souhaitez plus recevoir ces alertes.

Révocation des autorisations

Les applications peuvent permettre aux utilisateurs de révoquer des autorisations préalablement accordées. Par exemple, vous pouvez intégrer à votre application une page de paramètres permettant aux utilisateurs de désactiver l’envoi de messages sur leur adresse e-mail. Cette page de paramètres peut également proposer une option afin de révoquer en même temps l’autorisation email.

Vous pouvez révoquer une autorisation particulière en passant un appel à un point de terminaison de l’API Graph :

DELETE /{user-id}/permissions/{permission-name}

Cette demande doit être envoyée avec un token d’accès utilisateur ou le token d’accès de l’application actuelle. Si la demande a bien été envoyée, vous recevrez une réponse avec la valeur true.

Révocation de la connexion

Vous pouvez également permettre aux utilisateurs d’annuler toutes les autorisations associées à une application ou de révoquer la connexion. Pour ce faire, passez un appel à ce point de terminaison de l’API Graph :

DELETE /{user-id}/permissions

Cette demande doit être envoyée avec un token d’accès utilisateur valide ou le token d’accès de l’application actuelle. Si la demande a bien été envoyée, votre application reçoit une réponse avec la valeur true. Si l’appel est bien passé, le token d’accès utilisateur de cette personne deviendra non valide et elle devra donc à nouveau se connecter. Étant donné que toutes les autorisations de l’application ont été annulées, l’utilisateur devra accorder les autorisations à votre application comme s’il se connectait pour la première fois.

Guides des plateformes

AndroidiOSWeb