SDK login
Overview
Before using any D1 SDK service, the issuer application shall provide a proof of the end user authentication. The D1 SDK and D1 backend rely on this proof to authorize the issuer application to access D1 services.
For example, the issuer application prompts the end user to use the biometric authentication method that has been set up.
Prerequisites
During project onboarding, the issuer generates a key pair and share the public part with the Thales delivery team.
Login flow
Before calling any SDK operation, the issuer application shall login as detailed in the following flow:
Prerequisite
Issuer certificate is exchanged with Thales
Consumer is registered in D1 backend
SDK is properly initialized
Proof of authentication
D1 supports OpenID access token as proof of authentication, so by default, this is compatible with OpenID Identity Provider (IDP).
The issuer access token format is defined here.
The issuer access token must be created with a short expiration period such as a few minutes and must not be reused for multiple login attempts.
For iOS devices, device passcode must be set. Otherwise, an error message
Key generation failedwill be thrown.
Login validity
Once the end user is logged into the D1 services, the end user is granted access to D1 services during the full logged-in session, which by default is set to one hour. However, sensitive D1 services have a shorter login validity period (few minutes) and require the end user to re-authenticate if the end user login is older than this short validity period.
The D1 service call would return a NOT_LOGGED_IN error in such cases. The issuer application should request the end user to login again when this error is encountered.
Implementation
Before proceeding with the login flow, you have to convert the issuer JWT access token to a UTF-8 data type.
The following code snippets demonstrate how to login to D1 SDK on the different platforms:
Multiple issuers and consumers
The updated login API introduces support for multiple D1Task instances and enables the authentication with multiple issuer tokens, each representing different consumer IDs (issuer aggregators).
The key features are:
Single Login with Multiple Tokens You can perform a one-time login using any
D1Taskinstance by supplying all relevant issuer tokens. Each token can contain its own consumer IDs, allowing you to authenticate across multiple issuers in a single step.Cross-instance Access After logging in, you can seamlessly use any
D1Taskinstance to perform operations without requiring re-authentication. This offers unified access for multiple consumers and issuer aggregators within the same application.
Multiple D1Task instances
D1Task instancesYou can create multiple instances of D1Task for different issuers and consumers as follows:
Login with a multi-issuer token
The sub field of an issuer token may include multiple consumer IDs. When this field is present, the IDs are concatenated into a single space-delimited string. For example:
AccessToken Sample for multi consumerIDs and multi issuerIDs:
The first issuer token ISSUER_ID_1 includes a sub field containing both CONSUMER_ID_1 and CONSUMER_ID_2. The second issuer token ISSUER_ID_2 contains the sub for CONSUMER_ID_1 only. The Login API can be invoked using any previously created D1Task, and subsequent operations can proceed without requiring an additional login.
Logout for all multi-issuer token
New API has been introduced to allow application to invalidate all tokens. Refer to logoutAll.
Apple Wallet Extension
Apple Wallet Extension is able to add multiple cards with multiple issuerIds and multiple consumerIds.
Application must use new API issuerParamsList to initialize issuer application.
Application must use new API to authenticate on UI extension.
Last updated
Was this helpful?