Skip to main content
Pour utiliser les fonctionnalités de Highly Regulated Identity, vous devez avoir un Enterprise Plan avec le module complémentaire Highly Regulated Identity. Consultez la tarification Auth0 pour en savoir plus.
Highly Regulated Identity (HRI) est la solution Financial-Grade Identity™ d’Auth0 conçue pour sécuriser les opérations liées à des données sensibles et les services essentiels à votre entreprise. Initialement destinée aux secteurs hautement réglementés comme la finance et les soins de santé, Highly Regulated Identity rehausse le niveau de sécurité pour protéger un large éventail de cas d’utilisation, y compris, sans s’y limiter, les transferts d’argent, les paiements numériques et l’accès aux dossiers médicaux. Vous pouvez aussi utiliser Highly Regulated Identity pour d’autres opérations sensibles qui exigent une sécurité renforcée, par exemple pour approuver des modifications aux identifiants administratifs, sécuriser l’accès privilégié à un portail Web, et plus encore. Pour sécuriser vos opérations d’affaires sensibles, Highly Regulated Identity offre :

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

OpenID FAPI est un ensemble de spécifications en matière de sécurité et de protection des renseignements personnels élaboré par la Foundation. Les API conformes aux normes FAPI sont classées comme étant de « calibre financier », ce qui signifie qu’elles offrent des mécanismes robustes d’authentification et d’autorisation qui contribuent à 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 apportées pour satisfaire aux normes FAPI, consultez les sections suivantes : Pour en savoir plus sur FAPI, consultez le livre blanc d’OpenID Open Banking, Open Data, and Financial-grade APIs ainsi que les spécifications du groupe de travail FAPI.

​
Authentification forte du client (SCA)

Introduite par la directive sur les services de paiement (PSD2) de l’Union européenne, l’authentification forte du client (SCA) impose l’utilisation d’au moins deux facteurs d’authentification distincts parmi les trois suivants :
  • Quelque chose que l’utilisateur connaît (p. ex., un mot de passe)
  • Quelque chose que l’utilisateur possède (p. ex., un appareil)
  • Quelque chose qui est propre à l’utilisateur (p. ex., une empreinte digitale)
Les facteurs d’authentification doivent être indépendants afin que la compromission de l’un ne compromette pas les autres. La SCA devient rapidement la norme mondiale pour protéger les données et les services sensibles. Pour faciliter la conformité à la SCA, Auth0 offre divers facteurs d’authentification pour inscrire les utilisateurs et leur présenter une demande de vérification pendant une transaction de connexion. Highly Regulated Identity s’appuie sur les facteurs d’authentification suivants pour sécuriser vos transactions :
  • Notifications push sur mobile
  • SMS
  • Email
  • WebAuthn
À l’aide d’Actions, vous pouvez déterminer dynamiquement quels facteurs d’authentification utiliser. Vous bénéficiez ainsi de la souplesse nécessaire pour personnaliser la logique de votre code. Par exemple, vous pouvez ajouter un deuxième facteur d’authentification pour les paiements de plus de 10 USD. Pour en savoir plus, consultez Apply dynamic policy.

​
Liaison dynamique

La DSP2 exige que les fournisseurs de services de paiement mettent en œuvre la liaison dynamique ainsi que l’authentification forte du client. La liaison dynamique présente à l’utilisateur les détails de la transaction pour qu’il les valide et les approuve explicitement, et elle lie de manière unique l’autorisation à ces détails de transaction. Cela garantit une bonne expérience utilisateur et favorise la conformité réglementaire. Pour activer la liaison dynamique, vous pouvez utiliser Rich Authorization Requests (RAR) pour transmettre des données d’autorisation de transaction granulaires au point de terminaison d’autorisation. L’exemple de code suivant montre un objet JSON authorization_details, qui contient des renseignements comme le type de paiement, le montant, la devise et le destinataire :
authorization_details se voit attribuer une référence de transaction unique, qu’Auth0 utilise pour demander à l’utilisateur d’effectuer une authentification renforcée :
  • Utilisez des notifications push pour afficher les détails de la transaction et obtenir une approbation sur un appareil distinct, comme une application mobile.
  • Utilisez le SMS, le 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 transmettez pas de données d’autorisation de transaction granulaires ni d’autres données sensibles ou réglementées à l’extérieur de authorization_details.
Si l’utilisateur confirme les détails, la transaction se poursuit et Auth0 émet un associé aux authorization_details désormais approuvées. Les développeurs peuvent aussi ajouter la référence de transaction unique au jeton d’accès. Ainsi, vos serveurs d’API peuvent ensuite valider les détails de la transaction approuvée lorsqu’ils reçoivent et traitent des requêtes d’API. Pour en savoir plus sur RAR, consultez Flux du code d’autorisation avec Rich Authorization Requests.

​
Protection de la confidentialité et de l’intégrité

Les détails d’autorisation peuvent inclure des numéros de compte, des montants, des noms de commerçants et d’autres renseignements très sensibles transmis dans des URL ou des jetons d’accès non sécurisés. Pour protéger les données sensibles contre les accès non autorisés et toute altération, Highly Regulated Identity offre une protection complète de la confidentialité et de l’intégrité.

​
Protéger les données sensibles dans le front channel

Pour protéger les données sensibles dans le front channel, par exemple dans un navigateur Web, Highly Regulated Identity offre les solutions suivantes dans le cadre du profil de sécurité avancée FAPI 1.

​
Requêtes d’autorisation poussées (PAR)

PAR introduit un nouvel endpoint qui permet aux clients d’envoyer directement la charge utile d’une requête d’autorisation OAuth 2.0 au (c.-à-d. Auth0, dans ce cas). Cela évite de faire passer les paramètres d’autorisation par le front channel non sécurisé (c.-à-d. le navigateur), ce qui réduit le risque qu’un intermédiaire accède sans autorisation aux paramètres d’autorisation. Pour en savoir plus sur PAR, consultez flux du code d’autorisation avec des requêtes d’autorisation poussées (PAR) et Configurer les requêtes d’autorisation poussées (PAR).

​
Requête d’autorisation sécurisée par JWT (JAR)

JAR est une extension du protocole OAuth2 qui renforce la sécurité des requêtes d’autorisation. Pour ce faire, elle utilise un paramètre de requête (JWT) afin de protéger l’intégrité et, au besoin, la confidentialité des paramètres de la requête d’autorisation. Pour en savoir plus sur JAR, consultez Flux du code d’autorisation avec requêtes d’autorisation sécurisées par JWT (JAR) et Configurer les requêtes d’autorisation sécurisées par JWT (JAR).

​
Protéger 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, Highly Regulated Identity offre un soutien pour utiliser JSON Web Encryption (JWE) afin de chiffrer la charge utile des jetons d’accès. Cela protège les jetons d’accès contre les fuites de données du côté des applications et contre l’inspection non autorisée des appels d’API par des intermédiaires. Pour en savoir plus sur JWE, consultez JSON Web Encryption et Configurer JSON Web Encryption.

​
Authentification renforcée des applications

Pour renforcer la sécurité de l’authentification de votre application, Highly Regulated Identity offre deux options dans le cadre du profil FAPI 1 Advanced Security :
  • Private Key JWT : cette méthode consiste à générer une paire de clés publique-privée servant d’informations d’authentification pour authentifier une application. Elle est déjà offerte aux clients du forfait Enterprise. Pour en savoir plus, consultez Private Key JWT Authentication.
  • mTLS for OAuth : cette méthode consiste à enregistrer un certificat X.509 standard lié à une application dans votre tenant. Le certificat peut être émis par une AC ou être auto-signé. Conformément aux procédures mTLS standard, la clé privée correspondant au certificat est utilisée côté client pour établir le tunnel mTLS lors de l’envoi de requêtes vers les points de terminaison de votre tenant Auth0. Auth0 peut ainsi authentifier l’application sans transmettre de secrets sur le réseau. Pour en savoir plus, consultez mTLS for OAuth.
Avec Private Key JWT et OAuth 2.0 mTLS, vous pouvez effectuer la rotation des informations d’authentification sans interruption en conservant temporairement deux clés et/ou certificats actifs en même temps pour une application donnée.

​
Protéger les jetons d’accès avec Token Binding

La prise en charge de mTLS permet aussi d’utiliser Token Binding ou Sender Constraining. Token Binding associe l’empreinte du certificat client utilisé pour établir le tunnel mTLS à un jeton d’accès. Lorsque le client appelle une API à l’aide du jeton d’accès lié au certificat, le serveur d’API peut alors vérifier si le client utilise aussi le certificat client associé. Par conséquent, même si le jeton d’accès est compromis, des personnes malveillantes qui ne connaissent pas le certificat client ne peuvent quand même pas accéder aux ressources protégées. Remarque : Token Binding fonctionne indépendamment de la méthode d’authentification de l’application et n’exige pas l’enregistrement préalable du certificat client. Pour en savoir plus, consultez Configure Sender Constraining.

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

Lors de la conception de solutions concrètes exigeant une sécurité de niveau financier, il est important de tenir compte de l’expérience utilisateur. Appliquer les mêmes flux d’authentification à toutes les transactions n’est pas aussi efficace que de les adapter dynamiquement en fonction des détails de la transaction et des cas d’utilisation. Vous pouvez personnaliser votre flux d’authentification à l’aide des Actions. Par exemple, une fois que l’utilisateur s’est connecté, vous pouvez examiner les détails de la transaction reçus au moyen de RAR, répertorier les facteurs d’authentification de l’utilisateur déjà configurés et validés, et utiliser des services externes, comme des moteurs d’évaluation des risques, pour déterminer le prochain facteur d’authentification à utiliser. Pour en savoir plus, consultez Apply dynamic policy. Les nouveaux modèles vous permettent aussi de personnaliser les attributs affichés sur l’écran d’approbation de la transaction selon le type de transaction et d’autres détails d’autorisation. Pour en savoir plus, consultez Configure Rich Authorization Requests (RAR).

​
En savoir plus

Pour savoir comment Highly Regulated Identity fonctionne de bout en bout pour autoriser une transaction ponctuelle, consultez Autorisation transactionnelle avec le flux de code d’autorisation.