Authentification et informations d’identification
Architecture et Authentification
Pour comprendre comment fonctionne l’authentification de l’API DCP, vous avez besoin d’un aperçu de l’architecture de l’API DCP, illustrée ci‑dessous.
Lorsque vous appelez une API DCP, le point d’entrée est l’Adaptateur DCP, la seule API DCP publique.
Lorsqu’il est appelé, l’Adaptateur DCP valide d’abord vos identifiants d’Authentification d’Application. Voir la section ci‑dessous pour plus d’informations.
Si vos identifiants sont valides, votre requête est routée vers l’API DCP processus, qui appelle ensuite les systèmes backend du BRP.
Cependant, pour que votre requête aboutisse, vous devez être autorisé à utiliser l’API DCP ; sinon, vous recevrez un statut 401 Unauthorized.
❗ ❗ Lorsque nous commençons à travailler sur une API DCP, nous devons demander l’accès en créant un ticket de certification dans Jira, comme décrit dans la section Activités de Certification avec Jira. ❗ ❗
Si vous avez déjà commencé à travailler sur une API et que vous avez perdu l’accès, créez un ticket de support comme décrit dans la section Ouvrir un Ticket de Support.
Types d'authentification
Les API DCP utilisent 2 types d'authentification :
- La plupart des API utilisent l'authentification d'application.
- Quelques API spécifiques utilisent l'authentification de concessionnaire.
Dans la section Catalogue API , le type d'authentification utilisé par chaque API est indiqué.
Authentification d'application
L'authentification d'application est une authentification basée sur un jeton oAuth 2.0. Un ensemble d'identifiants est créé pour chaque DSP dans chaque environnement.
Notez que si vous avez à la fois un DMS et un CRM et que vous intégrez les 2 types d’API DCP, quatre jeux d’identifiants sont créés pour vous :
- DMS en test
- DMS en production
- CRM en test
- CRM en production
Les identifiants DMS et CRM ne sont pas interchangeables !
❗ ❗ Lorsque vous commencez à travailler sur une API DCP, nous devons demander l’accès en créant un ticket de certification dans Jira, comme décrit dans la section Activités de certification avec Jira. ❗ ❗
Si vous avez déjà commencé à travailler sur une API et que vous avez perdu l’accès, créez un ticket de support comme décrit dans la section Ouvrir un ticket de support.
Les identifiants n’expirent normalement jamais et ne sont jamais révoqués (sauf si vous quittez DCP).
Cependant, les identifiants peuvent changer, donc votre implémentation doit vous permettre de facilement modifier et utiliser de nouveaux identifiants.
Obtenir un jeton d’accès
Vous obtenez le jeton oAuth 2.0 d'authentification d'application en appelant le API d'authentification d'application.
Le jeton oAuth 2.0 reçu est utilisé comme jeton Bearer pour authentifier le DSP lors de l'appel aux API DCP.
Le jeton oAuth 2.0 expirera 30 minutes après avoir été émis.
Une fois expiré, un code d'état 401 est retourné lors de l'appel à une API DCP.
Vous devriez implémenter un processus automatisé pour générer un nouveau jeton toutes les 25 minutes.
Authentification du concessionnaire
L'authentification du concessionnaire est plus complexe et est utilisée lorsque le DSP et le concessionnaire doivent être identifiés.
La première étape consiste pour le concessionnaire à se connecter en utilisant son compte BOSSweb, qui est le portail des concessionnaires BRP implémenté avec Salesforce. Un code d'autorisation est retourné au DSP.
La deuxième étape consiste à enregistrer le jeton d'actualisation reçu.
La troisième étape consiste à obtenir un jeton d'accès OAuth 2.0 en utilisant le code d'autorisation reçu.
Connexion DSP BOSSWeb
Pour tester votre mécanisme d'authentification du concessionnaire et les API DCP utilisant l'authentification du concessionnaire, un compte BOSSWeb avec un numéro de concessionnaire spécifique est créé pour vous dans l'environnement de test.
Les informations concernant ce compte BOSSWeb de test vous sont envoyées par l'équipe DCP.
Aucun compte BOSSWeb ne sera créé pour vous en production !
Configuration
Avant d'appeler le service d'authentification du concessionnaire, des identifiants doivent être créés et des URL de redirection doivent être configurées pour le DSP dans Salesforce. L'équipe DCP crée un ensemble d'identifiants pour chaque environnement, et le DSP utilise ces identifiants pour appeler le service de gestion des comptes concessionnaires.
Le DSP doit fournir une URL de redirection pour chaque environnement.
Salesforce utilise l'URL de redirection pour renvoyer le code d'autorisation lorsque le concessionnaire se connecte.
❗ ❗ L’URL utilisée dans l’appel au API d'authentification du concessionnaire doit correspondre EXACTEMENT à celle que vous avez fournie pour la configuration ❗ ❗
Si l’URL que vous avez fournie pour l’environnement de production est https://site, vous devez utiliser la même URL dans le paramètre redirect lors de l’appel à l’ API d'authentification du concessionnaire.
Si vous utilisez https://site/ ou https://Site dans le paramètre redirect, vous recevrez une erreur :
Obtenir un code d’autorisation
Le DSP lance le processus d’authentification et récupère un code d’autorisation en appelant le service de gestion des comptes concessionnaires.
Le code d’autorisation est renvoyé via l’URL de redirection, et le DSP l’utilise pour obtenir un jeton d’accès.
Le code d’autorisation expirera dans les 5 minutes.
Une fois expiré, un code de statut 401 est renvoyé lors de l’appel à une API DCP.
Obtenir un jeton d’accès
Le jeton d’autorisation est utilisé pour appeler le service de gestion des comptes concessionnaires afin d’obtenir les jetons d’accès et d’actualisation.
Le jeton d’accès oAuth 2.0 reçu est utilisé comme jeton porteur pour authentifier le DSP lors de l’appel des API DCP.
Le jeton d’accès oAuth 2.0 expirera 2 heures après son attribution.
Une fois expiré, un code d’état 401 est retourné lors de l’appel d’une API DCP.
Vous devez implémenter un processus automatisé pour générer un nouveau jeton toutes les 90 minutes en utilisant le jeton d’actualisation.
Jeton d’actualisation
Lorsque vous recevez le jeton d’actualisation, enregistrez‑le dans le profil du concessionnaire et réutilisez‑le pour obtenir le jeton d’accès.
Une fois le jeton d’accès expiré, le DSP peut utiliser le jeton d’actualisation et appeler le service de gestion des comptes concessionnaires pour obtenir un nouveau jeton d’accès.
Le jeton oAuth 2.0 reçu est utilisé comme jeton porteur pour authentifier le DSP lors de l’appel des API DCP.
Le jeton d’actualisation reste valide jusqu’à sa révocation et doit être réutilisé pour chaque appel d’actualisation.
Vous devez enregistrer le jeton d’actualisation localement ; il ne sera pas renvoyé à chaque appel d’actualisation.
Le jeton d’accès doit être renouvelé avant son expiration.
Même si le jeton d’accès a expiré, le jeton de rafraîchissement reste valide !
Le jeton d’accès est spécifique au concessionnaire !
Un aspect important de l’authentification des concessionnaires est que le jeton d’accès est spécifique au numéro de concessionnaire utilisé pour obtenir le code d’autorisation.
Si vous obtenez un code d’autorisation pour le concessionnaire 0000694650 et appelez une API DCP pour effectuer une opération pour le concessionnaire 0000691730, vous recevrez un code d’état 403 Forbidden.