强客户认证解析_AI阅读总结 — 包阅AI

Strong Customer Authentication (or SCA for short) is a versatile authorization mechanism that first made waves in the financial services industry for digital payments, and adoption is picking up pace, even for non-financial transactions.

SCA was enacted in 2019 as a requirement of the revised European Union (EU) Payment Services Directive (PSD2). Its main purpose is to raise security standards and reduce fraud for online and contactless payments, and it’s now a part of life for millions of consumers in the EU.

PSD2 and its regulatory technical standards (RTS), along with inputs from the European Banking Authority in the form of opinions, questions, and answers, describe how SCA should be implemented by financial services organizations in EU member states. In summary and in relation to user security and authentication, this means:

• The payer needs to authenticate themselves with multi-factor authentication in order to authorize the payment.
• Multi-factor authentication (MFA) must comprise two (or more) of the following elements: knowledge, possession, and inherence.
• The payer (the consumer) gives informed consent to the payment amount and the payee’s account.
• The payment transaction must be (cryptographically) linked to an amount and a payee specified by the payer (known as Dynamic Linking – this is what makes SCA different from typical “step-up MFA”).

In this blog post, we’ll explore these SCA components and show how you can implement them using Auth0 by Okta!

Exemptions from Applying SCA

Strong Customer Authentication takes a risk-based approach, and there is a provision for exemptions to be applied to SCA. Low-risk scenarios that allow service providers not to apply SCA include:

• Payments to existing payees that have been previously authorized using SCA.
• Payments from one account to another account, where both accounts belong to the same account holder and are with the same service provider.
• The service provider has judged the payment transaction to be low risk through real-time risk and fraud analysis. The level of historic fraud will determine the threshold for amounts that can be exempted from SCA; i.e., lower levels of fraud will mean higher payment amounts can be exempt from SCA.
• Payments transactions below EUR 30 (or local equivalent) are considered “low value” and may be exempt from SCA. Service providers will have to request the payer to perform an SCA if the exemption has been used five times since the payer’s last successful SCA or if the sum total of previously exempted payments exceeds EUR 100 (or local equivalent).

Multi-Factor Authentication — Something You Know, Have, or Are

As discussed earlier, SCA mandates the use of at least two distinct authentication factors out of the three categories: knowledge, possession, and inherence.

• The knowledge factor is something the user knows, such as a password, a personal identification number (PIN), or an answer to a security question.
• The possession factor is something the user has, such as a telephone SIM card, a mobile device, or a smart card. Each of these typically has a cryptographic key, so the possession factor is essentially possession of a cryptographic key, preferably the private key of an asymmetric key pair.
• The inherence factor is something you are and is typically biometric verification where a user’s captured biometric is compared to a reference template. This can be, for example, a fingerprint, facial, or voice biometric.

Consent

Authorizing payments and any other sensitive transaction requires that the user know what they are authorizing and consenting to. SCA requires the user to view the payee and the payment amount before any authorization.

This concept of providing informed consent can also apply outside of payment scenarios for any sensitive transactions such as:

• Changing login and/or security settings
• Changing user profile settings, e.g., home address
• Sharing personal data

Dynamic Linking — What Makes SCA Different

Dynamic Linking is what sets SCA apart from a regular step-up authentication prompt. Linking transaction details to the approval prompt allows users to double-check accuracy and avoid transaction tampering before approving the transaction.

When a payer (the consumer) initiates a payment, the transaction itself must be linked to the amount and payee specified by the payer. This dynamic linking generates an “authentication code,” which is unique and specific to the transaction (payee and amount).

The authentication code is transferred through the payment and authorization processes. Any changes to the payment data (amount, payee) will invalidate the authentication code and, thus, the transaction.

If you want to learn more about the details of SCA, here are some related documents:

Strong Customer Authentication with Auth0 by Okta

Highly Regulated Identity (HRI) is a solution suite on the Customer Identity Cloud powered by Auth0 that delivers Financial Grade Identity™ that helps organizations elevate security, privacy, and user experience beyond login. HRI enables developers to meet the high levels of security required by companies operating within highly regulated industries like banking, insurance, and health care. You can also use HRI for other sensitive operations that require enhanced security, such as users updating their account information, admin or security settings, accessing sensitive data or apps, and more.

Here, we look at how Highly Regulated Identity can be used to build a Strong Customer Authentication solution.

Solution architecture

The diagram below describes a possible architecture and interactions for a Strong Customer Authentication solution built on Auth0 by Okta using HRI features.

Important points to note:

• The blue components are Okta-owned and part of Auth0 and Highly Regulated Identity solution suite.
• The green components are built and maintained by the customer, e.g., customer mobile apps, applications, and services.

Sequence of operations

1. The user has initiated a payment transaction via their web browser at a digital banking web application, e.g., they may be making a payment from their bank account.

2. The digital banking web application sends the transaction request to Auth0:

   a. The transaction request may contain the “authentication code” for the amount and payee as part of the transaction.

   b. The request is sent to the /par endpoint and avoids exposing sensitive transaction details at the browser.

3. Auth0 validates the request and generates:

   a. A linking_id when the Consent Policy is configured as “Transactional Authorization with MFA” and the API audience is configured with this Consent Policy.

   b. A request_uri as a reference to the next step in the authorization process.

4. Auth0 sends the request_uri back to the calling web application .

5. The web application redirects the browser with the redirect_uri, which opens the login page in Auth0:

   a. The user can perform the login with their knowledge-based factor (i.e. their password).

   b. This login step can be avoided if there is already a single sign-on session.

   c. The user will wait here on this “holding page” until the decoupled flow completes.

6. Meanwhile, a post-login trigger can run custom an Action code that extracts the authorization details (e.g., amount, payee, authentication code) from the transaction request.

   a. At this point, the Action code can integrate with third-party risk and fraud engines to determine whether a step-up authentication (i.e., SCA) is needed.

7. The Action writes the linking_id and contextual authorization details into a message store, i.e., a data store, for future retrieval.

8. Auth0 performs a lookup for the MFA mechanism to use; here, we will use a mobile push notification to a custom mobile app which embeds the Okta Guardian SDK:

   a. Auth0 sends a mobile push notification to the mobile app, along with the linking_id.

   b. No transaction details are sent over the push notification.

9. The customer mobile app receives the push notification with the transaction linking_id and calls the message store to retrieve the transaction details for the user to authorize and consent to.

10. The customer mobile app extracts the authorization details for the requested transaction, i.e., payment amount and payee, and displays this to the user for consent.

    a. The user reviews the transaction details and proceeds to accept or decline.

11. The customer mobile app with embedded Guardian SDK calls the Okta MFA endpoint with the result of the user authorization:

    a. Was the MFA action completed successfully or not?

    b. If the MFA was completed successfully, did the user accept or decline?

12. Once the mobile push-based MFA completes, the web browser is redirected from Auth0 and the MFA page back to the digital banking web application:

    a. The digital banking web application receives an authorization code.

13. The digital banking web application exchanges the authorization code for an access token:

    a. The access token contains the details from the original transaction request, including the payment amount and payee and “authentication code”.

14. The digital banking application uses the access token to consume APIs in order to initiate the payment transaction in the appropriate back-end systems.

15. The user is informed of the outcome of the payment transaction.

Supported authentication mechanisms

The solution architecture describes SCA using a mobile push notification to a customer’s mobile app with embedded Guardian SDK. However, there are alternative options that are also compliant with SCA:

• Authentication by one-time passcode (OTP) sent via SMS.
• Authentication by WebAuthn.

For both of these authentication options, the user performs the authentication on the login page and then is shown the transaction details to authorize and consent to.

Final Words

The Highly Regulated Identity solution suite on Auth0 delivers Strong Customer Authentication for financial services and payments. The SCA solution also applies to non-payment use cases and can be applied to any sensitive operation where step-up authentication, user authorization, and consent are required.

You can read more about Highly Regulated Identity on the Auth0 by Okta documentation.