Passer au contenu principal
Pour utiliser les fonctionnalités de l’identité très réglementée (HRI), vous devez disposer d’un plan Enterprise avec le module complémentaire Identité très réglementée. Consultez Tarification Auth0 pour plus de détails.
L’Identité très réglementée est la solution Financial-Grade Identity™ d’Auth0 pour sécuriser les opérations et services de données sensibles importants pour votre entreprise. Visant principalement les secteurs fortement réglementés tels que la finance et la santé, l’Identité très réglementée renforce les mesures de sécurité pour protéger divers cas d’utilisation des clients, incluant notamment les transferts d’argent, les paiements numériques et l’accès aux dossiers médicaux. Vous pouvez également utiliser l’Identité très réglementée pour des opérations sensibles supplémentaires nécessitant une sécurité accrue, comme l’approbation des modifications des informations d’identification administratives, la sécurisation de l’accès privilégié à un portail Web, ainsi que pour d’autres tâches nécessitant une protection renforcée. Pour sécuriser vos opérations commerciales sensibles, l’Identité très réglementée propose :

​
Sécurité avancée avec OpenID Connect (FAPI)

OpenID FAPI est une suite de spécifications de sécurité et de confidentialité développées par la Fondation . Les API conformes aux normes FAPI sont classées comme « de qualité financière », ce qui indique qu’elles offrent des mécanismes d’authentification et d’autorisation robustes pour sécuriser l’accès aux données et services financiers ainsi qu’à d’autres données et services sensibles. Auth0 est un fournisseur FAPI certifié. Pour en savoir plus sur les améliorations de sécurité que nous avons introduites pour répondre aux normes FAPI, veuillez consulter les sections suivantes : Pour plus d’informations sur FAPI, veuillez consulter OpenID Open Banking, Open Data et les API de qualité financière livre blanc et Spécifications du groupe de travail FAPI.
null

​
Authentification forte du client (SCA)

null
Introduite par la Directive sur les services de paiement (PSD2)d’Europe, l’authentification forte du client impose l’utilisation d’au moins deux facteurs d’authentification distincts parmi les trois suivants :
  • Quelque chose que l’utilisateur connaît (par exemple, un mot de passe)
  • Quelque chose que l’utilisateur possède (par exemple, un appareil)
  • Quelque chose d’intrinsèque à l’utilisateur (par exemple, une empreinte digitale)
Les facteurs d’authentification doivent être indépendants, de sorte que le fait d’en compromettre un ne compromette pas les autres. L’authentification forte du client est rapidement considérée comme la norme mondiale en matière de protection des données et des services sensibles. Pour favoriser la conformité avec l’Authentification forte du client, Auth0 propose divers facteurs d’authentification qui enregistrent et vérifient les utilisateurs lors d’une transaction de connexion. L’identité très réglementée exploite les facteurs d’authentification suivants pour sécuriser vos transactions :
  • Notifications poussées mobiles
  • SMS
  • Courriel
  • WebAuthn
En utilisant Actions, vous pouvez déterminer dynamiquement les facteurs d’authentification à utiliser. Cela vous donne la flexibilité de personnaliser la logique de votre code. Par exemple, vous pouvez ajouter un deuxième facteur d’authentification pour les paiements supérieurs à 10 USD. Pour en savoir plus, veuillez consulter Appliquer la politique dynamique.

​
Liens dynamiques

La Directive sur les services de paiement (DSP2) exige que les prestataires de services de paiement mettent en œuvre la liaison dynamique ainsi qu’une Authentification forte du client (SCA). La liaison dynamique affiche à l’utilisateur les détails de la transaction pour obtenir sa validation et son approbation explicites, en associant de manière unique l’autorisation aux détails de la transaction. Cela garantit une bonne expérience utilisateur et contribue à la conformité réglementaire. Pour activer la liaison dynamique, vous pouvez utiliser Demandes d’autorisation riches (RAR) pour transmettre des informations détaillées sur les autorisations de transaction au point de terminaison . L’exemple de code suivant montre un objet JSON, authorization_details qui contient des informations telles que le type de paiement, le montant, la devise et le destinataire : 
"authorization_details": [
 {
   "type": "one_time_payment",
   "amount": {
     "amount": 2460.46,
     "currency": "USD"
   },
   "sourceAccount": "xxxxxxxxxxx4567",
   "recipient": "Acme Travel, Inc.",
   "concept": "All Inclusive Resort Package for Two",
 }
]
authorization_details se voit attribuer une référence de transaction unique, qu’Auth0 utilise pour inviter l’utilisateur à effectuer une authentification renforcée :
  • Utilisez les notifications poussées pour afficher les détails de la transaction et obtenir l’approbation sur un appareil distinct tel qu’une application pour téléphone mobile.
  • Utilisez SMS, courriel ou WebAuthn pour confirmer les détails sur l’appareil à l’origine de la transaction une fois que l’utilisateur a terminé le deuxième facteur d’authentification.
Ne pas transmettre de données d’autorisation de transaction détaillées ou d’autres données sensibles ou réglementées en dehors de authorization_details.
Si l’utilisateur confirme les détails, la transaction se poursuit et Auth0 émet un jeton d’accès avec les autorisations désormais approuvées. Les développeurs peuvent également ajouter la référence de transaction unique au jeton d’accès. Par conséquent, vos serveurs API seront en mesure de valider ultérieurement les détails de la transaction approuvée lors de la réception et du traitement des demandes API. Pour en savoir plus sur RAR, veuillez consulter Flux de code d’autorisation avec demandes d’autorisation riches.

​
Confidentialité et protection de l’intégrité

Les numéros de compte, les montants monétaires, les noms de commerçants et d’autres informations très sensibles peuvent être inclus dans les détails de l’autorisation. Ces informations sont transmises via des URL ou des jetons d’accès, qui ne sont pas toujours sécurisés. Pour protéger les données sensibles contre les accès non autorisés et les falsifications, l’Identité très réglementée assure une protection complète de la confidentialité et de l’intégrité.

​
Protégez les données sensibles sur le canal frontal

Pour garantir la protection des données sensibles sur le canal frontal, tel qu’un navigateur Web, l’Identité très réglementée propose les solutions suivantes selon le profil de sécurité avancé FAPI 1.

​
Demandes d’autorisation poussées (PAR)

PAR introduit un nouveau point de terminaison, qui permet aux clients de pousser directement la charge utile d’une demande d’autorisation OAuth 2.0 vers le serveur d’autorisation (c’est-à-dire Auth0 dans ce cas). En évitant de transmettre les paramètres d’autorisation via le canal frontal non sécurisé (comme le navigateur), cela réduit le risque d’accès non autorisé aux paramètres par des intermédiaires. Pour en savoir plus sur PAR, veuillez consulter Flux de code d’autorisation avec demandes d’autorisation poussées (PAR) et Configurer les demandes d’autorisation poussées (PAR).

​
Demandes d’autorisation sécurisées JWT (JAR)

JAR est une extension du protocole OAuth2 qui renforce la sécurité des demandes d’autorisation. Cela se fait en utilisant un paramètre de requête Jeton Web JSON () pour protéger l’intégrité et, éventuellement, la confidentialité des paramètres de requête d’autorisation. Pour en savoir plus sur JAR, veuillez consulter Flux de code d’autorisation avec demandes d’autorisation poussées JWT (JAR) et Configurer les demandes d’autorisation poussées JWT (JAR).

​
Protégez les données sensibles dans les jetons d’accès

Pour protéger les détails d’autorisation inclus dans les jetons d’accès, l’Identité très réglementée fournit un support pour l’utilisation Chiffrement Web JSON (JWE) pour crypter la charge utile des jetons d’accès. Cela permet de protéger les jetons d’accès contre les violations de données côté application et contre l’inspection non autorisée des appels d’API par des intermédiaires. Pour en savoir plus sur JWE, veuillez consulter Chiffrement Web JSON et Configurer le chiffrement Web JSON.

​
Authentification renforcée des applications

Pour renforcer la sécurité de l’authentification de votre application, l’Identité très réglementée propose deux alternatives distinctes dans le cadre du profil de sécurité avancé FAPI 1 :
  • Clé privée JWT : implique la génération d’une paire de clés publique-privée à utiliser comme informations d’identification pour authentifier une application. La Clé privée JWT est déjà disponible pour les clients du plan Enterprise. Pour en savoir plus, veuillez consulter Authentification par clé privée JWT.
  • mTLS pour OAuth : implique l’enregistrement d’un certificat X.509 standard lié à une application sur votre locataire. Le certificat peut être émis par une autorité de certification ou auto-signé. En suivant les procédures standard de mTLS, la clé privée associée au certificat est utilisée par le client pour établir le tunnel mTLS lorsqu’il envoie des requêtes à vos points de terminaison de locataire Auth0. Par conséquent, Auth0 peut authentifier l’application sans transmettre de secrets sur le réseau. Pour en savoir plus, veuillez consulter mTLS pour OAuth.
Avec les deux, la clé privée JWT et OAuth 2.0 mTLS, vous pouvez effectuer une rotation des informations d’identification sans interruption en conservant temporairement deux clés et/ou certificats actifs simultanément pour une application donnée.

​
Protection des jetons d’accès avec liaison de jeton

La prise en charge de mTLS permet également d’utiliser la liaison de jeton ou la contrainte d’expéditeur. La liaison de jeton associe l’empreinte numérique du certificat client utilisé pour établir le tunnel mTLS à un jeton d’accès. Lorsque le client accède à une API en utilisant un jeton d’accès lié au certificat, le serveur API peut vérifier si le client utilise également le certificat client associé. Ainsi, même si le jeton d’accès est compromis, les acteurs malveillants qui ne possèdent pas le certificat client ne pourront pas accéder aux ressources protégées. Remarque : La pré-inscription du certificat client n’est pas nécessaire pour la liaison de jeton, qui fonctionne indépendamment de la méthode d’authentification de l’application. Pour en savoir plus, veuillez consulter Configurer la contrainte d’expéditeur.

​
Flux d’approbation personnalisable pour une meilleure expérience utilisateur

Il est crucial de prendre en compte l’expérience utilisateur lors de la conception de solutions visant une sécurité de niveau financier. L’ajustement dynamique en fonction des détails des transactions et des cas d’utilisation est plus efficace que l’application de flux d’authentification uniformes pour toutes les transactions. Vous pouvez personnaliser votre flux d’authentification à l’aide d’actions. Par exemple, après que l’utilisateur se soit connecté, vous pouvez examiner les détails de la transaction reçus via RAR, vérifier les facteurs d’authentification enregistrés et validés de l’utilisateur, et utiliser des services externes, comme des moteurs d’évaluation des risques, pour déterminer le facteur d’authentification à utiliser ensuite. Pour en savoir plus, veuillez consulter Appliquer la politique dynamique. Les nouveaux modèles de connexion universelle vous offrent également la possibilité de personnaliser les attributs affichés à l’écran d’approbation des transactions, en fonction du type de transaction et des autres détails d’autorisation. Pour en savoir plus, veuillez consulter Configuration des demandes d’autorisation riches (RAR).

​
En savoir plus

Pour savoir comment l’Identité très réglementée fonctionne de bout en bout pour permettre l’autorisation d’une transaction unique, veuillez consulter Autorisation transactionnelle avec authentification client contextuelle forte.
⌘I