Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Compréhension de la sécurité et de l'authentification

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

  • Comprendre les méthodes de sécurité et d'authentification utilisées dans les applications Salesforce.
  • Comprendre l'utilisation des applications connectées pour l'intégration d'applications mobiles au serveur Salesforce.
  • Comprendre la terminologie de base d'OAuth.
  • Comprendre le flux d'événements de l'authentification OAuth et de la sécurité grâce à un code PIN.

Sécurité et authentification

Une authentification sécurisée est essentielle à l'exécution d'applications professionnelles sur les appareils mobiles. OAuth 2.0, le protocole standard du secteur, permet une autorisation sécurisée pour accéder aux données d'un client, sans indiquer de nom d'utilisateur et de mot de passe. Il est souvent décrit comme la clé valet d'accès au logiciel. Une clé valet limite l'accès à certaines fonctionnalités de votre voiture. Par exemple, un voiturier ne peut pas ouvrir le coffre ou la boîte à gants avec la clé valet.

Les développeurs d'applications mobiles peuvent facilement et rapidement intégrer la mise en œuvre d'OAuth 2.0 à Salesforce. Cette mise en œuvre utilise un affichage HTML pour recueillir le nom d'utilisateur et le mot de passe, qui sont ensuite envoyés au serveur. Ce dernier émet alors un jeton de session ainsi qu'un jeton d'actualisation permanent, qui sont stockés sur l'appareil en prévision des futures interactions.

Pour se connecter à Salesforce, une application mobile utilise une application connectée Salesforce. Une application connectée permet au développeur et à l'administrateur de contrôler comment l'application se connecte et qui y a accès. Ainsi, une application connectée peut restreindre l'accès à un groupe de clients, définir ou autoriser une plage IP, etc.

Terminologie OAuth

Si vous êtes perdu(e), cette liste peut vous aider à retrouver votre chemin. Prises ensemble, ces étiquettes peuvent vous mener directement au nirvana OAuth.
Remarque

Remarque

Le terme « consommateur » de cette liste désigne toujours l'application Mobile SDK. De son côté, un consommateur humanoïde est appelé « utilisateur » ou « utilisateur final ».

Clé consommateur
Valeur utilisée par le consommateur (dans ce cas précis, l'application du kit de développement mobile) afin de s'identifier dans Salesforce. Désignée par client_id.
Jeton d'accès
Valeur utilisée par le consommateur pour accéder au nom de l'utilisateur à des ressources protégées, au lieu d'utiliser les identifiants Salesforce de l'utilisateur. Le jeton d'accès est un ID de session et peut être utilisé directement.
Jeton d'actualisation
Jeton utilisé par le client pour obtenir un nouveau jeton d'accès, sans nouvelle approbation de l'accès par l'utilisateur final.
Code d'autorisation
Jeton de courte durée représentant l'accès accordé par l'utilisateur final. Le code d'autorisation est utilisé pour obtenir un jeton d'accès et un jeton d'actualisation.
Application connectée
Application externe à Salesforce qui utilise le protocole OAuth pour vérifier l'utilisateur Salesforce et l'application externe.

Flux d'authentification OAuth2

Le flux d'événements au cours d'une autorisation OAuth dépend de l'état de l'authentification sur l'appareil.

Flux d'autorisation initiale

  1. Le client ouvre l'application Mobile SDK.
  2. Une invite d'authentification s'affiche.
  3. Le client saisit un nom d'utilisateur et un mot de passe.
  4. L'application envoie les identifiants du client à Salesforce, qui en retour reçoit un ID de session confirmant la réussite de l'authentification.
  5. Le client accepte la requête de l'application pour accorder l'accès à l'application.
  6. L'application démarre.

Autorisation en cours

  1. Le client ouvre une application mobile.
  2. Si l'ID de la session est actif, l'application démarre immédiatement. Si l'ID de la session est obsolète, l'application utilise le jeton d'actualisation de la première autorisation afin d'obtenir un ID de session actualisé.
  3. L'application démarre.

Sécurité par un code PIN

Les applications connectées Salesforce bénéficient d’un niveau de sécurité supplémentaire grâce à une protection de l’application par un code PIN. Ce code PIN ne concerne que l'application mobile et est différent du code PIN de l'appareil ou des informations de connexion fournies par l'organisation Salesforce.

Pour pouvoir utiliser un code PIN, le développeur doit sélectionner la case Verrouillage de l’écran et code PIN lors de la création de l’application connectée. Les administrateurs de l'application mobile peuvent alors appliquer une protection à l'aide d'un code PIN, personnaliser la durée d'une session ou encore paramétrer la longueur du code PIN.

Remarque

Remarque

Étant donné que la sécurité par code PIN est implémentée dans le système d’exploitation de l’appareil, cette fonctionnalité n’est pas disponible dans les applications web en HTML5.

Dans les faits, un code PIN peut être appliqué afin que l'application mobile se verrouille lorsqu'elle n'est pas utilisée pendant une durée prédéfinie. Lorsque l'application passe en arrière-plan, l'horloge continue à tourner.

Voici une illustration de la manière dont fonctionne une protection par code PIN :
  1. Le client allume son téléphone et insère le code PIN de l'appareil.
  2. Le client lance une application du kit de développement mobile.
  3. Le client saisit les informations de connexion à l'organisation Salesforce.
  4. Le client saisit son code PIN pour l’application du kit de développement mobile.
  5. Le client travaille dans l'application et la place en arrière-plan lorsqu'il en ouvre une autre (ou reçoit un appel, etc.).
  6. La session de l'application expire.
  7. Le client rouvre l’application et l’écran du code PIN s’affiche (pour l’application du kit de développement mobile, pas pour l’appareil).
  8. Le client saisit le code PIN de l'application et peut reprendre son travail.

Flux de l'agent-utilisateur OAuth2

Avec le flux de l’agent-utilisateur, l’application connectée, qui intègre l’application cliente à l’API Salesforce, reçoit le jeton d’accès en tant que redirection HTTP. L’application connectée demande au serveur d’autorisation de rediriger l’agent-utilisateur vers un serveur Web ou une ressource locale accessible. Le serveur Web peut extraire le jeton d’accès de la réponse et le transmettre à l’application connectée. Par sécurité, la réponse du jeton est fournie sous forme de fragment de hashtag (#) dans l’URL. Ce format évite la transmission du jeton au serveur ainsi qu’à d’autres serveurs dans des en-têtes référents.

Avertissement

Avertissement

Le jeton d’accès étant codé dans l’URL de redirection, il peut être exposé à l’utilisateur et aux autres applications sur l’appareil.

Remarque

Remarque

Les applications connectées de ces types de clients peuvent protéger le secret client de chaque utilisateur. Cependant, le secret client est accessible et exploitable, car les exécutables du client résident sur l’appareil de l’utilisateur. Pour cette raison, le flux utilisateur-agent n’utilise pas le secret client. L’autorisation repose sur la stratégie de même origine de l’agent-utilisateur. En outre, le flux de l’agent-utilisateur ne prend pas en charge les publications hors bande.

Flux d'agent-utilisateur
Imaginons que vous utilisiez le kit de développement Mobile SDK de Salesforce pour créer une application mobile pouvant rechercher des coordonnées de clients au sein de votre organisation Salesforce. Le kit de développement Mobile SDK met en œuvre le flux d’autorisation de l’agent-utilisateur OAuth 2.0 dans votre application connectée, en l’intégrant à votre API Salesforce et en lui autorisant l’accès aux données définies. Le flux suit les étapes suivantes :
  1. L’utilisateur final ouvre l’application mobile.
  2. L’application connectée dirige l’utilisateur vers Salesforce afin d’authentifier et d’autoriser l’application mobile.
  3. L’utilisateur approuve l’accès pour ce flux d’autorisation.
  4. L’application connectée reçoit le rappel de Salesforce vers l’URL de redirection, qui extrait l’accès et actualise les jetons.
  5. L’application connectée utilise le jeton d’accès afin d’accéder aux données pour le compte de l’utilisateur final.

Applications connectées

Une application connectée intègre une application à Salesforce en utilisant des API. Les applications connectées utilisent des protocoles d'authentification standard SAML et OAuth, fournissent une authentification unique ainsi que des jetons à utiliser avec les API Salesforce. En plus des fonctionnalités standard de OAuth, les applications connectées permettent aux administrateurs Salesforce de définir diverses stratégies de sécurité et de contrôler explicitement qui peut utiliser les applications correspondantes.

Voici la liste générale des informations que vous fournissez en créant une application connectée.
  • Nom, description, logo et coordonnées
  • URL où Salesforce peut localiser l'application pour l'autorisation ou l'identification
  • Protocole d’autorisation : OAuth, SAML ou les deux
  • Plages IP à partir desquelles les utilisateurs peuvent se connecter à l’application connectée (facultatif)
  • Informations sur des politiques mobiles que l’application connectée peut imposer (facultatif)

Les applications Salesforce Mobile SDK utilisent des applications connectées pour accéder aux services OAuth de Salesforce et pour appeler les API REST de Salesforce.

Valeurs de paramètre d'étendue

OAuth nécessite que la configuration de l'étendue soit effectuée pour le serveur comme pour le client. L'accord entre les deux parties définit le contrat d'étendue.

  • Côté serveur : définit les permissions d’étendue d’une application connectée sur le serveur Salesforce. Ces paramètres permettent de déterminer les niveaux d’accès que les applications clientes, comme les applications du kit de développement mobile, sont en droit de demander. Faites en sorte que les réglages OAuth de votre application connectée correspondent au minimum aux spécifications de votre code. Pour la plupart des applications, refresh_token, web, et api suffisent.
  • Côté client : spécifie les demandes d'étendue dans votre application du kit de développement mobile. Les demandes d'étendue du client doivent être un sous-ensemble des permissions d'étendue de l'application connectée.

Configuration côté serveur

Vous pouvez définir les valeurs de paramètre d’étendue suivantes :
Valeur Description
api Permet d'accéder au compte de l'utilisateur actuellement connecté à l'aide d'API telles que l'API REST ou l'API de transfert en masse. Ces valeurs comprennent également chatter_api, ce qui permet d'accéder aux ressources de l'API REST Chatter.
chatter_api Permet d'accéder uniquement aux ressources de l'API REST Chatter.
custom_permissions Autorise l'accès aux autorisations personnalisées dans une organisation associée à l'application connectée, et indique si chaque autorisation est activée pour l'utilisateur connecté.
complet Permet d'accéder à toutes les données accessibles par l'utilisateur connecté et englobe toutes les autres étendues. Full ne renvoie pas un jeton d’actualisation. Pour obtenir un jeton actualisé, vous devez demander l'étendue refresh_token de façon explicite.
ID Permet d'accéder au service des URL d'identité. Vous pouvez demander profile, email, address ou phone individuellement pour obtenir le même résultat qu'en utilisant id ; ils sont tous équivalents.
openid Permet d'accéder à l'identificateur unique de l'utilisateur actuellement connecté pour les applications OpenID Connect.

Utilisez le périmètre openid dans le flux utilisateur-agent OAuth 2.0 et le flux d'authentification de serveur Web OAuth 2.0 afin de recevoir un jeton d'ID signé conforme aux spécifications OpenID Connect, en plus du jeton d'accès.

refresh_token Permet de renvoyer un jeton d'actualisation lorsque vous êtes autorisé(e) à en recevoir un. L'application peut ensuite interagir avec les données d'un utilisateur hors ligne et est synonyme d'une demande offline_access.
visualforce Permet d'accéder aux pages Visualforce crées par des clients. Ne permet pas d’accéder aux interfaces utilisateur Salesforce standard.
web Permet d’utiliser le jeton access_token sur le Web, et inclut visualforce, pour permettre d’accéder aux pages Visualforce crées par des clients.
Remarque

Remarque

Pour les applications du kit de développement mobile, vous devez toujours sélectionner refresh_token dans les paramètres de l'application connectée côté serveur. Même si vous sélectionnez l'étendue full, vous devez tout de même sélectionner explicitement refresh_token.

Configuration côté client

Les règles suivantes régissent la configuration de l'étendue pour les applications du kit de développement mobile.

Étendue

Configuration de l'application du kit de développement mobile

refresh_token

Implicitement requis par le kit de développement mobile pour votre application, pas besoin de l'inclure dans la liste des étendues de votre application.

api

À inclure si vous faites des appels d’API REST Salesforce (s’applique à la plupart des applications).

web

À inclure si votre application a accès aux pages définies dans une organisation Salesforce (pour toute application qui télécharge les pages Web basées sur Salesforce.)

complet

À inclure pour demander toutes les autorisations. (Le kit de développement mobile demande implicitement refresh_token pour vous.)

chatter_api

À inclure si votre application appelle les API REST Chatter.

ID

(pas nécessaire)

visualforce

Utilisez web à la place.

Création d'une application connectée

La création d'une application connectée est simple, mais nécessite des droits d'administrateur. Dans votre organisation Developer Edition ou Trailhead Playground, ces autorisations vous sont automatiquement accordées.

  1. Dans votre Trailhead Playground ou organisation Developer Edition, accédez à Configuration.
  2. Suivez l'une des étapes ci-dessous.
    • Si vous utilisez Salesforce Classic, sélectionnez Créer | Applications, accédez à Applications connectées, puis cliquez sur Nouveau.
    • Si vous utilisez Lightning Experience, sélectionnez Applications | Gestionnaire d’applications, puis cliquez sur Nouvelle application connectée.
  3. Sous Informations de base, remplissez le formulaire comme suit :
    • Nom d'application connectée : <Nom de votre choix ; peut inclure des espaces>
    • Nom d'API : acceptez la valeur proposée.
    • E-mail du contact : saisissez votre adresse e-mail.
  4. Sous API (Activer les paramètres OAuth), cochez Activer les paramètres OAuth.
  5. Configurez l’URL de rappel sur : <n’importe quelle chaîne d’URL, réelle ou fictive, par exemple monappexemple://auth/success>. Si la saisie automatique offre une suggestion, ne l'acceptez pas. Saisissez à la place l'URL de rappel.
  6. Sous Domaines OAuth disponibles, sélectionnez :
    • Accéder à vos données et les gérer (api)
    • Fournir l'accès à vos données via le Web (web)
    • Effectuer à tout moment des requêtes en votre nom (refresh_token, offline_access)
    Cet ensemble minimal d'étendues fonctionne correctement pour la plupart des applications Mobile SDK.
  7. Cliquez sur Ajouter.
  8. Si votre organisation utilise une authentification s’appuyant sur le navigateur (également appelée « authentification avancée »), décochez la case Nécessite un secret pour le flux serveur Web.
  9. Cliquez sur Enregistrer.
Après avoir enregistré la configuration, notez les détails de votre nouvelle application connectée.
  • L'URL de rappel hélas Clé consommateur. Vous copiez ces valeurs dans la configuration de votre application Mobile SDK avant de la distribuer.
  • Les applications Mobile SDK n’utilisent pas de secret de consommateur. Par conséquent, vous pouvez ignorer cette valeur.

Vous connaissez l'architecture et la sécurité Mobile SDK, il est temps de vous exercer avec Mobile SDK. Pour commencer, relevez le défi ci-dessous qui nécessite seulement une organisation Developer Edition ou Trailhead Playground. Nous recommandons ensuite de compléter le projet Configuration de vos outils de développeur Mobile SDK.