Autorisation transactionnelle avec authentification contextuelle forte du client
Découvrez comment l’identité très réglementée permet l’autorisation transactionnelle avec l’authentification contextuelle forte du client.
L’identité très réglementée permet l’autorisation transactionnelle avec l’authentification contextuelle forte du client (SCA) en appliquant l’authentification renforcée par étapes SCA et la liaison dynamique pour autoriser une transaction spécifique. Il demande à l’utilisateur un deuxième facteur d’authentification pour autoriser explicitement les détails de la transaction d’une opération ponctuelle. Cette méthode est utile pour les cas d’utilisation suivants qui requièrent une sécurité de niveau financier :
Sécurisation des opérations sensibles exécutées à partir de vos propres services, telles que l’approbation des virements bancaires, l’accès à l’historique des opérations et la modification des identifiants d’accès.
Sécurisation des opérations sensibles demandées à des services tiers, telles que l’approbation des paiements numériques et l’autorisation d’un accès unique pour la vérification d’un compte.
Cet article vous présente le parcours de bout en bout de l’approbation d’un virement bancaire. Le même flux d’autorisation transactionnelle peut être appliqué à d’autres cas d’utilisation.
Vous devez configurer l’autorisation transactionnelle pour chaque API. Une fois activée, elle s’applique aux permissions et aux authorization_details.types de cette API.
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.
Le diagramme suivant montre le flux de bout en bout de l’autorisation transactionnelle avec SCA contextuel. Il y a quatre phases principales :
Redirection sécurisée de l’utilisateur vers Auth0 avec les détails de la transaction. Dans cette étape, il faut éviter de révéler des informations sensibles sur le frontend (par exemple, le navigateur).
Appliquer une politique dynamique après l’authentification de l’utilisateur. En utilisant Actions, vous pouvez décider dynamiquement des étapes suivantes en fonction des détails de la transaction et d’autres informations que vous pouvez obtenir de sources telles que des API externes. Pour en savoir plus, consultez Appliquer une politique dynamique.
Mettre au défi l’utilisateur avec un deuxième facteur d’authentification et afficher les détails de la transaction pour que l’utilisateur l’approuve explicitement. Cette étape dépend du facteur d’authentification que vous avez choisi d’appliquer à l’aide des Actions.
Obtenez le jeton d’accès et procédez à l’opération sensible. Votre API valide les détails de la transaction approuvée associés au jeton d’accès.
Nous examinerons chaque phase en détail dans les sections suivantes.
Communiquer les détails de la transaction et rediriger vers Auth0
L’utilisateur accède pour la première fois à votre application Web après s’être authentifié auprès d’Auth0. Dans notre exemple de cas d’utilisation, l’utilisateur demande ensuite un transfert d’argent à l’un de ses contacts.Pour répondre aux normes de sécurité financière, l’identité très réglementée utilise des requêtes d’autorisation poussées pour cacher les détails de la transaction au navigateur. Au lieu d’envoyer des paramètres de requête via le navigateur au point de terminaison /authorize, PAR envoie directement des paramètres de votre système dorsal à un point de terminaison spécial /par à l’aide d’une requête POST. Pour savoir comment le configurer, consultez Configurer les demandes d’autorisation poussées.Dans le corps de la requête PAR, les détails de la transaction sont envoyés dans le cadre de l’objet JSON authorization_details :
Copier
"authorization_details": [ { "type": "money_transfer", "instructedAmount": { "amount": 150, "currency": "USD" }, "sourceAccount": "xxxxxxxxxxx1234", "destinationAccount": "xxxxxxxxxxx9876", "beneficiary": "Hanna Herwitz", "subject": "A Lannister Always Pays His Debts" }]
Utilisez les Actions pour inspecter les authorization_details afin de déterminer les facteurs d’authentification à utiliser en fonction de la transaction. Pour en savoir plus sur authorization_details et sur la manière de l’utiliser avec PAR, consultez Flux de code d’autorisation avec des demandes d’autorisation enrichies.Si vous souhaitez répondre aux exigences de conformité en matière de sécurité avancée de FAPI 1, vous devez également utiliser la cryptographie à clé publique pour authentifier le système dorsal par rapport au point de terminaison /par ou /token. Cette méthode est plus sûre que l’envoi d’un secret client. Auth0 propose les méthodes d’authentification par cryptographie à clé publique suivantes :
Après avoir reçu une réponse positive à votre requête PAR, redirigez l’utilisateur vers le point de terminaison /authorize de votre locataire Auth0. Ajoutez le paramètre request_uri reçu dans la réponse PAR et le client_id comme seuls paramètres de requête, cachant ainsi efficacement toute information sensible au navigateur.
Lorsque l’utilisateur se connecte sans utiliser le et que le navigateur accède au point de terminaison /authorize de votre locataire Auth0, Auth0 tente d’authentifier l’utilisateur. Dans notre exemple d’approbation d’un virement bancaire, Auth0 a déjà authentifié l’utilisateur pour accéder à votre application Web. Cependant, lorsqu’un tiers redirige l’utilisateur, par exemple pour un paiement numérique, Auth0 présente un écran de connexion à l’utilisateur. Pour en savoir plus sur le flux d’authentification, consultez la documentation Authentifier.Une fois que Auth0 a authentifié avec succès l’utilisateur, Auth0 déclenche des Actions post-connexion, qui exposent les détails de la transaction concernant l’utilisateur, l’application, le(s) facteur(s) d’authentification utilisé(s), et plus encore dans l’objet événement post-login. Dans l’objet événement post-connexion, la propriété event.transaction.requested_authorization_details contient des détails sur la demande d’autorisation reçue à l’étape précédente.Utilisez l’objet événement post-connexion pour décider de la manière dont vous souhaitez poursuivre la transaction. Par exemple, vous pouvez envoyer les détails de la transaction à un moteur de risque externe et, après avoir évalué le niveau de risque, déterminer s’il convient de demander une authentification renforcée par SMS, comme l’illustre l’exemple de code suivant.
Copier
exports.onExecutePostLogin = async (event, api) => { if (event.transaction?.requested_authorization_details.some(e => e.type === 'money_transfer')) { const axios = require('axios'); //details to contact risk evaluation engine const risk_url = 'https://risk.example.org/score'; const risk_options = { headers: { 'Content-Type': 'application/json' } }; const tx_data = { email: event.user.email, authorization_details: event.transaction?.requested_authorization_details }; //send operation details to risk evaluation engine var risk = await axios.post(risk_url, tx_data, risk_options); //if it is a risky operation use push to authorize if (risk.data.score >= 2) { api.authentication.challengeWith({ type: 'push-notification', options: {otpFallback: false}}); } }};
L’action post-connexion expose également event.transaction.linking_id, qui contient un identifiant universel unique (UUID) de la transaction. Plus tard, lorsque Auth0 demande à l’utilisateur d’approuver la transaction, linking_id fournit une référence pour Liaison dynamique. Vous pouvez également ajouter le linking_id au jeton d’accès en tant que demande personnalisée pour associer les détails d’autorisation d’une transaction spécifique aux appels API de votre côté. Cela facilite la traçabilité, car Auth0 inclut le linking_id dans les journaux du locataire.
Mettre au défi l’utilisateur pour obtenir l’approbation des détails de la transaction
Vous pouvez personnaliser le facteur d’authentification à utiliser en fonction des facteurs inscrits par l’utilisateur, des facteurs déjà satisfaits par la session et/ou de vos propres préférences. Vous pouvez également proposer des alternatives à l’utilisateur. Pour en savoir plus, consultez Personnaliser la sélection MFA dans la nouvelle connexion universelle.En outre, pour les SMS, les courriels et WebAuthn, vous pouvez personnaliser l’écran de consentement qu’Auth0 présente à l’utilisateur avec les informations que vous souhaitez afficher à partir de authorization_details et d’autres détails de la transaction. Pour en savoir plus, consultez Configurer les demandes d’autorisation enrichies. Pour les notifications poussées, cela ne s’applique pas car c’est l’application mobile qui présente les détails de la transaction à l’utilisateur final.Les sections suivantes expliquent les différents facteurs d’authentification que vous pouvez configurer pour l’autorisation transactionnelle.
Envoyez une notification poussée à l’appareil mobile enrôlé d’un utilisateur pendant qu’Auth0 invite l’utilisateur à afficher l’écran d’attente de l’authentification multifacteur () sur l’appareil utilisé (par exemple, l’ordinateur portable d’où provient la transaction).
Pour les notifications poussées, l’application mobile est chargée de montrer les détails de la transaction à l’utilisateur pour approbation explicite. Pour ce faire, à l’aide d’Actions, stockez les détails de la transaction que vous souhaitez montrer à l’utilisateur avec le linking_id sur un serveur ou un point de terminaison externe et mettez-les à disposition pendant quelques minutes seulement. Ensuite, invitez l’utilisateur à envoyer une notification poussée, comme illustré dans l’exemple de code suivant. N’oubliez pas d’interdire la possibilité de revenir à la saisie manuelle d’un mot de passe à usage unique (OTP) en ajoutant l’option otpFallback: false.
Copier
exports.onExecutePostLogin = async (event, api) => { if (event.transaction?.requested_authorization_details.some(e => e.type === 'money_transfer')) { const axios = require('axios'); //details to store tx_details in external server const tx_server_url = 'https://consent.example.org/transactions'; const tx_server_options = { headers: { 'Content-Type': 'application/json' } }; const tx_data = { email: event.user.email, authorization_details: event.transaction?.requested_authorization_details, linking_id: event.transaction.linking_id }; //store the transaction details in an external endpoint var response = await axios.post(tx_server_url, tx_data, tx_server_options); //event.transaction.linking_id is automatically added to the push challenge api.authentication.challengeWith({ type: 'push-notification', options: {otpFallback: false}}); //add unique transaction_id to access token for traceablity api.accessToken.setCustomClaim('transaction_id', event.transaction.linking_id); }};
vous pouvez appeler api.multifactor.enable('any', { allowRememberBrowser: false }) avant api.authentication.challengeWith pour supprimer l’option permettant de se souvenir de cet appareil et obliger l’utilisateur à valider le défi poussé pour toutes les transactions.
La notification poussée inclut le event.transaction.linking_id, que la trousse SDK Gardien Auth0 transmet à l’application mobile. Pendant la transaction, le nom de la propriété est abrégé à txlnkid. Avec le linking_id, l’application mobile peut maintenant récupérer les détails de la transaction et les montrer à l’utilisateur. Une fois que l’utilisateur approuve ou refuse l’opération, l’application mobile peut autoriser ou rejeter le défi MFA respectivement. La transaction passe à la phase Compléter l’opération.Remarque : Pour vérifier l’identité de l’utilisateur qui ouvre la notification poussée, vous pouvez ajouter l’authentification biométrique à l’application mobile. Pour en savoir plus, consultez Configurer WebAuthn avec la biométrie de l’appareil pour MFA.
Vous pouvez également configurer le téléphone, le courriel ou WebAuthn comme facteurs d’authentification pour mettre au défi l’utilisateur. Pour ces facteurs d’authentification, Auth0 invite l’utilisateur à consulter l’écran d’attente de la MFA correspondant. Une fois que l’utilisateur a validé le défi sur l’écran d’attente de la MFA, Auth0 montre les détails de la transaction à l’utilisateur pour qu’il les approuve explicitement. N’oubliez pas que vous devez Configurer les demandes d’autorisation enrichies (RAR) pour que l’étape d’approbation fonctionne correctement.Pour le facteur d’authentification par téléphone, Auth0 envoie un code de vérification à l’utilisateur par SMS ou vocalement. La capture d’écran suivante montre l’écran d’attente de la MFA après qu’Auth0 a envoyé le code par SMS :
vous pouvez appeler api.multifactor.enable('any', { allowRememberBrowser: false }) avant api.authentication.challengeWith pour supprimer l’option permettant de se souvenir de cet appareil et obliger l’utilisateur à valider le défi poussé pour toutes les transactions.
L’utilisateur reçoit ensuite le SMS contenant le code de vérification.Une fois que l’utilisateur a saisi le code de vérification dans l’écran d’attente de la MFA, Auth0 l’invite à fournir les détails de la transaction sur un écran de consentement. Une fois que l’utilisateur a approuvé ou refusé les détails de la transaction, celle-ci passe à la phase Compléter l’opération.Le courriel et Webauthn utilisent le même flux d’approbation transactionnelle et des écrans d’attente et d’approbation explicite de la MFA similaires.
Dans le cadre de la PSD2, le courriel n’est pas un facteur d’authentification valide pour l’authentification efficace des clients. Nous vous conseillons d’utiliser un autre facteur d’authentification pour conduire les utilisateurs à se conformer aux exigences de la PSD2.
Si vous ne demandez pas à l’utilisateur un deuxième facteur d’authentification, Auth0 lui propose l’écran de consentement pour obtenir une approbation explicite des détails de la transaction.
Pour compléter l’opération, Auth0 suit le Flux de code d’autorisation standard. Si la transaction est approuvée, le navigateur de l’utilisateur est redirigé vers votre application avec un code d’autorisation, qui est ensuite échangé contre un jeton d’accès chiffré à l’aide du Chiffrement Web JSON. Le jeton d’accès contient les authorization_details que vous avez transmis à l’origine. L’exemple de code suivant montre le contenu d’un jeton d’accès déchiffré :
Transmettez le jeton d’accès à l’API qui facilite le transfert d’argent. L’API vérifie alors les authorization_details du jeton d’accès pour vérifier les détails de la transaction, tels que le montant, l’expéditeur, la destination, etc. Une fois vérifié, le transfert d’argent s’exécute avec succès et vous devriez voir apparaître l’écran d’approbation.Si la transaction est rejetée à une étape quelconque, le navigateur de l’utilisateur affiche un code d’erreur access_denied.
