Welcome to our new developer portal! Use the "Ask" button to chat with our AI Agent.

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.

Example: end user biometric authentication.

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

SDK login flow.

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.

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 D1Task instance 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 D1Task instance to perform operations without requiring re-authentication. This offers unified access for multiple consumers and issuer aggregators within the same application.

Multiple D1Task instances

You 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?