Découvrez Highly Regulated Identity, la solution Financial-Grade Identity d’Auth0.
Pour utiliser les fonctionnalités de Highly Regulated Identity, vous devez disposer d’un plan Enterprise avec le module complémentaire Highly Regulated Identity. Consultez Auth0 Pricing pour en savoir plus.
Highly Regulated Identity (HRI) est la solution Financial-Grade Identity™ d’Auth0 conçue pour sécuriser les opérations sur des données sensibles et les services essentiels à votre entreprise. Initialement destinée aux secteurs fortement réglementés comme la finance et la santé, Highly Regulated Identity renforce le niveau de sécurité afin de protéger un large éventail de cas d’utilisation, notamment les transferts d’argent, les paiements numériques et l’accès aux dossiers médicaux. Vous pouvez également utiliser Highly Regulated Identity pour d’autres opérations sensibles nécessitant une sécurité renforcée, par exemple pour approuver des changements apportés aux identifiants d’administrateur, sécuriser l’accès privilégié à un portail web, et plus encore.Pour sécuriser les opérations sensibles de votre entreprise, Highly Regulated Identity offre :
OpenID FAPI est une suite de spécifications de sécurité et de protection de la vie privée élaborée par la Foundation. Les API conformes aux normes FAPI sont classées comme étant « de niveau 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 certifié FAPI. Pour en savoir plus sur les améliorations de sécurité que nous avons apportées pour respecter les normes FAPI, consultez les sections suivantes :
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 qui permettent d’inscrire les utilisateurs et de leur demander une vérification lors d’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
Courriel
WebAuthn
À l’aide des Actions, vous pouvez déterminer dynamiquement quels facteurs d’authentification utiliser. Cela vous donne la flexibilité 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 Appliquer une stratégie dynamique.
La DSP2 exige que les fournisseurs de services de paiement mettent en œuvre la liaison dynamique en plus de l’authentification forte du client. La liaison dynamique présente à l’utilisateur les détails de la transaction afin qu’il puisse les valider et les approuver explicitement, et associe de façon unique l’autorisation aux détails de la transaction. Cela garantit une bonne expérience utilisateur et aide à respecter les exigences réglementaires.Pour activer la liaison dynamique, vous pouvez utiliser Rich Authorization Requests (RAR) pour transmettre au point de terminaison d’autorisation des données d’autorisation de transaction détaillées. 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 après que l’utilisateur a terminé le deuxième facteur d’authentification.
Ne transmettez pas de données d’autorisation de transaction très détaillées ni 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 associé aux authorization_details désormais approuvés. 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 transaction approuvés lorsqu’ils reçoivent et traitent des requêtes d’API.Pour en savoir plus sur RAR, consultez Flux de code d’autorisation avec des demandes d’autorisation enrichies.
Protection de la confidentialité et de l’intégrité
Les données d’autorisation peuvent inclure des numéros de compte, des montants monétaires, 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 canal frontal
Pour protéger les données sensibles dans le canal frontal, comme dans un navigateur Web, Highly Regulated Identity offre les solutions suivantes dans le cadre du profil FAPI 1 Advanced Security.
PAR introduit un nouveau point de terminaison qui permet aux applications de transmettre directement le payload d’une requête d’autorisation OAuth 2.0 au (c.-à-d. Auth0 dans ce cas). On évite ainsi de faire transiter les paramètres d’autorisation par le canal frontal 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 de code d’autorisation avec requêtes d’autorisation poussées (PAR) et Configurer les requêtes d’autorisation poussées (PAR).
Protéger les données sensibles dans les jetons d’accès
Pour protéger les données d’autorisation incluses dans les jetons d’accès, Highly Regulated Identity permet d’utiliser JSON Web Encryption (JWE) pour chiffrer le payload des jetons d’accès. Cela protège les jetons d’accès contre les fuites de données côté application et contre l’inspection non autorisée des appels API par des intermédiaires.Pour en savoir plus sur JWE, consultez JSON Web Encryption et Configure JSON Web Encryption.
Pour renforcer la sécurité de l’authentification de votre application, Highly Regulated Identity propose 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’identifiants 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 associé à une application dans votre locataire. Le certificat peut être délivré par une AC ou autosigné. 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 locataire 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 faire la rotation des identifiants sans interruption de service en conservant temporairement deux clés et/ou certificats actifs en même temps pour une application donnée.
La prise en charge de mTLS permet également 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 l’application appelle une API à l’aide du jeton d’accès lié au certificat, le serveur d’API peut alors vérifier si elle utilise aussi le certificat client associé. Par conséquent, même si le jeton d’accès est compromis, des acteurs malveillants qui ne connaissent pas le certificat client ne peuvent pas accéder aux ressources protégées.Remarque : Token Binding fonctionne indépendamment de la méthode d’authentification de l’application et ne nécessite pas le préenregistrement du certificat client. Pour en savoir plus, consultez Configurer Sender Constraining.
Flux d’approbation personnalisables pour une meilleure expérience utilisateur
Lorsque vous concevez des solutions concrètes pour 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 ajuster dynamiquement selon les détails de la transaction et les cas d’utilisation.Vous pouvez personnaliser votre flux d’authentification à l’aide des Actions. Par exemple, après la connexion de l’utilisateur, vous pouvez examiner les détails de la transaction reçus via RAR, répertorier les facteurs d’authentification de l’utilisateur déjà inscrits et validés, et utiliser des services externes, comme des moteurs d’évaluation du risque, pour déterminer le prochain facteur d’authentification à utiliser. Pour en savoir plus, consultez Appliquer une stratégie dynamique.Les nouveaux modèles vous permettent également de personnaliser les attributs affichés à l’écran d’approbation de la transaction selon le type de transaction et d’autres détails d’autorisation. Pour en savoir plus, consultez Configurer Rich Authorization Requests (RAR).
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme
