3.0 Authentication Methods
- Matthew Bell
Contents
3.1 Overview
The API Standards will support both redirection and decoupled authentication to allow a Customer to use the same authentication mechanisms while using a Third Party as they use when accessing the API Provider directly.
The general principles that apply relating to authentication are:
API Providers authenticate a Customer: This needs to go through a Strong Customer Authentication (SCA) at the Customer’s API Provider for a Third Party request (i.e., access to information or payment initiation) and must be actioned by the API Provider.
Customers should have their normal authentication methods available: A Customer should be able to use the elements they prefer to authenticate with their API Provider if supported when interacting directly with their API Provider.
Parity of experience: The Customer experience when authenticating within a journey with a Third Party should involve no more delay or friction than the equivalent experience with their API Provider.
Once per session SCA: SCA should not be required more than once for a single session of access to account information or a single payment initiation.
No Obstacles: API Providers should not create unnecessary delay or friction during authentication including unnecessary or superfluous steps, attributes, or unclear language, e.g., advertising of API Providers products or services, language that could discourage the use of Third Party services or additional features that may divert the Customer from the authentication process (with the potential exception of services provided to vulnerable Customers).
3.2 Redirection based authentication
3.2.1 Browser based redirection - Account Information Services (AIS)
Customer authentication with the API Provider using browser based redirection from a Third Party for an Account Information Services request.
This enables a Customer to authenticate with their API Provider while using a Third Party for Account Information Services, using the same web based authentication method which the Customer uses when accessing the API Provider web channel directly.
This model works when the Customer is consuming the Third Party service on a device that does not have the API Provider app, or the Customer does not have the API Provider mobile app.
3.2.2 Browser based redirection - Payment Initiation Services (PIS)
Customer authentication with the API Provider using browser based redirection for a Payment Initiation Service request.
This enables a Customer to authenticate with their API Provider while via a Third Party for the Payment Initiation Service, using the same web based authentication method which they use when accessing the API Provider web channel directly.
This model works when the Customer is consuming the Third Party service on a device that does not have the API Provider app, or the Customer does not have the API Provider mobile app and is appliable to both one time only payments initiation customer journeys as well as when establishing an Enduring Payment Consent.
Variations
There are variations to this process. We have not shown the full journey breakdown for these variations but have listed them below (to be expanded upon as variations in use are identified through implementation):
The select account step (now as part of the first step – entering account details) could happen after the authentication step and will take place in the API Provider’s environment instead of the Third Party environment.
3.2.3 App based redirection - Account Information Services
Customer authentication with the API Provider using the API Provider mobile app installed on the same device on which the Customer is consuming the Third Party service.
Enables the Customer to authenticate with the API Provider while using a Third Party for Account Information Services using the same API Provider app based authentication method which they use when accessing the API Provider mobile channel directly.
Third Party service could be web based or app based. The redirection should directly invoke the API Provider app to enable the Customer to authenticate and should not require the Customer to provide any Customer identifier or other credentials to the Third Party. Redirections can only be done on the same device.
3.2.4 App based redirection - Payment Initiation Services
Customer authentication, with the API Provider using the API Provider mobile app installed on the same device on which the Customer is consuming the Third Party service.
Enables the Customer to authenticate with the API Provider while using a Third Party for Payment Initiation Services, using the same API Provider app-based authentication method that they use when accessing the API Provider mobile channel directly and is appliable to both one time only payments initiation customer journeys as well as when establishing an Enduring Payment Consent.
The Third Party service could be web based or app based. The redirection should directly invoke the API Provider app to enable the Customer to authenticate and should not require the Customer to provide any Customer identifier or other credentials to the Third Party.
3.3 App-to-browser redirection – Account Information Services
It is possible that a Customer using a mobile device does not have their API Provider mobile app installed, or their API Provider does not provide an app at all. In these instances, the Third Party app will need to launch the native mobile browser to present the Customer with their API Provider's web channel to authenticate.
3.4 Browser-to-app redirection
Conversely, a Third Party may be browser only, but this should not preclude a Customer from having their API Provider app invoked if the Customer is using a mobile browser and has the API Provider app installed on their device. In this situation the Third Party browser should invoke the app for authentication and following authentication the Customer needs to be redirected back to the Third Party browser.
If a Customer is using a desktop to access the Third Party, then under the redirection model the journey will have to be completed on the API Provider browser channel. Only with “Decoupled authentication” (see 3.6) can the Customer use their app to authenticate in this situation.
3.5 Effective use of redirection screens
Within a typical journey, a Customer is presented with two redirection screens, at the Third Party first then followed by the API Provider:
First message that informs the Customer they are moving from the Third Party domain to the API Provider domain.
Happens after the Customer has provided consent to the Third Party for the account information or payment initiation service.
Second message that informs the Customer they are moving back from the API Provider domain to the Third Party domain.
Happens after the API Provider has authenticated the Customer and completed the authorisation of the action with the Customer.
Research carried out by OBIE has suggested that the redirection screens are an important part of the process, providing the Customer with trust in the process. The following reasons are noted:
Helps the Customer navigate their online journey by informing them of what is going to happen next.
Creates a clear sense of separation between the Third Party domain and the API Provider domain.
Reassures the Customer that they are in control and helps engender trust.
3.6 Decoupled authentication
A major addition to the API Standards for v2.0.0, known as “Decoupled” authentication, allows for the flow to be completed with a Customer using a separate secondary device to authenticate with the API Provider.
To enable the flow the Customer uses a separate secondary device to authenticate with the API Provider. This model allows for a number of innovative solutions and has the added benefit of being able to take advantage of biometrics for Strong Customer Authentication (SCA), where they may be engaging with a Third Party through a separate device, such as a Point of Sale (POS) device.
We have used examples for a Payment Initiation Service journey, but the same principles apply for all Account Information Service journeys.
3.6.1 Model A: Static Customer identifier
A Decoupled authentication flow, where the Customer provides a static identifier to the Third Party which is used by the API Provider to notify the Customer, such that the Customer can authenticate using the API Provider app on a separate device or mobile application.
This enables the Customer to use the same app-based authentication method with the API Provider they use when accessing the API Provider mobile app directly.
This model is best suited to Third Party apps with good user input options (e.g., website on PC/laptop), using a supported identifier, for example Customer phone number, email address, debit card number. The exact type of identifier supported by the API Provider should be published by the API Provider.
3.6.2 Model B: API Provider generated identifier
A Decoupled authentication flow where the Customer provides a dynamic identifier generated with their API Provider to the Third Party which is then used by the API Provider to identify the Customer through the API Provider app to authenticate and action the Third Party request.
This model is best suited to a Third Party app that can "capture" the code from the API Provider app (e.g., by scanning a QR code).
Alternatively, the Customer can be prompted to type in an identifier in the Third Party App. This may however be a long series of characters and may result in a sub-optimal Customer experience.
3.6.3 Model C: Third Party generated identifier
A Decoupled authentication flow where the Customer is provided with an identifier generated by the Third Party, which is then used by the API Provider to identify the Customer through the API Provider app to authenticate and action the Third Party request.
This model is best suited to a Third Party app that provides a QR code to all API Providers to "capture" the code from the API Provider app (e.g., by scanning a QR code).
Alternatively, the Customer can be prompted to type in an identifier in the API Provider app. This may be a long series of characters and may result in a sub-optimal Customer experience.
3.6.4 Model D: Customer with a previously generated ID token
A Decoupled authentication flow where the Third Party provides the API Provider with an ID Token, generated by the API Provider from a previous consent authentication event. This is used by the API Provider to re-identify the Customer for a new authentication and authorisation event.
This model is ideally suited where the services offered by the Third Party involve POS, telephony, or where Customer interaction with the Third Party is not possible through a graphical interface (IoT devices), or even when the Customer may not be present within the Third Party channel.