Authentication

API - V 2.5

Download Swagger Spec

Introduction

The Authentication API provides the means to access all other APIs on DevX. For example, when calling an API to retrieve a list of an account holder’s accounts, your request must provide a valid OAuth 2.0 bearer token. The authentication service provides that token.

The service available through the Candescent Developer Hub provides tokens for two different grant types:

Client Credentials:

Used for trusted server-side applications
Sending a request passes a key-and-secret pair assigned to your application
Since the token is issued in the context of a Financial Institution (FI) rather than a user, no end-user login is required
Response provides the Bearer Token to be used to call other Developer Hub APIs

Password:

Best for first-party native applications (such as the FI’s own mobile application)
Request is sent with key-and-secret pair plus the customer’s username and password
Response provides Bearer Token to be used to call other Developer Hub APIs

NOTE: As of March 2020, the Authentication Service contains two proxies: one to be used to retrieve the Bearer Token for Developer Hub V1 APIs and another for Developer Hub V2 APIs. Please see the last section of this documentation for a list of V1 and V2 APIs currently exposed in the Developer Hub.

Though there are differences in the request headers and form data, both V1 and V2 Authentication work in the same manner:

Allow a registered application to obtain an OAuth2.0 Bearer Token, which is required when accessing the rest of the Digital Insight API suite
Utilize two grant types:
Client Credentials: used a digital banking customer isn’t present to provide their credentials but has trusted your application to act on their behalf
Password: used when the username and password of the digital banking customer are known

The selection of the grant type to use determines the parameter set expected by the request. The parameter list explicitly states the requirement for each grant type:
When Password is requested, the authentication request is made within the context of a customer. The success response will therefore contain their member ID and the scope of the token will be restricted to that customer.
When Client Credentials is requested, the success response will not contain any customer-specific data or scoping.

Note: The OAuth2.0 token will expire after 30 minutes, after which a subsequent request to this service is required.

System Requirements & Configurations

Endpoints for the Authentication service can be accessed from the Developer Hub.

This is the new oAuth2 token generation service. The auth token from this service is utilized by Accounts, Alerts and Messaging, Banking Image Services, Disclosures, Money Movement, Transactions. The service type in the Developer Hub is Authentication and the service subType is db-apx-tokens. The legacy oAuth token generation service is used by Banking Services and Customer services. This is generally referred to as legacy token generation service. The service type in the Developer Hub is Authentication and the service subType is db-oauth.

What is Supported?

  • Method:* POST
  • Endpoint Definition:* /v1/oauth/token
  • Request Headers:*
Name Type Description
di_tid * String Unique id used to identify the request. The id allows the request to be traced through the entire request and response flow.

The expected id is a UUID, in the canonical form e.g 123e4567-e89b-12d3-a456-426655440000
user-agent * String Identifies the application and the platform making the request.

The expected format is `{Appname}/{Appversion}[/{DeviceID}][;{Platform User-Agent}]` e.g. iPhone/1.0/abc12345;Nokia3110
di_fiid* String The financial institution for which the authentication token is being requested.

The scope of the OAuth2.0 token will be restricted to this Financial Institution.
offering_id String Uniquely identifies the name of the client app making the request.

When not provided this is derived based on a property held against the application within Apigee
originating_ip String The IP address of the device making the request for authentication.

If not provided the IP address logged will be the IP address extracted from the HTTP request

Note: this should be the originating device, rather than the client making the request e.g. if a mobile device is used the ip address should be that of the mobile device, rather than a back end service
Authorization* String Standard HTTP Basic Authentication based on the `consumer key` and `consumer secret` provided during the application registration process.

A string composed of `Basic`+ `(space)` + `base64encode(consumer_key + “:” + consumer_secret)`; example `Basic ODU4S0pRczVXwGdMRkhUUUhtSGhNdTRYHlpRa3N1ZGY6STA0UThtMFJZZEF1dUlwY


Get Token (for V2 APIs)

  • Method:* POST
  • Endpoint Definition:* /{baseurl}/v1/token
  • Request Headers:*
Name Type Description
Authorization * String Basic Auth - Base64 encoded client credentials
Content-Type * String Request content type
transactionId * String A unique identifier for this request.
institutionId * String Numeric unique id of the financial institution
Accept String



Additional Product Details

Sample Responses

V1 Client Credentials Response:


<token>
  <di_fiid>00000</di_fiid>
  <access_token>aLongGeneratedAlphanumericString</access_token>
  <expires_in>1799</expires_in>
</token>



V2 Client Credentials Response:

<token>
  <di_fiid>00000</di_fiid>
  <di_ficustomer>aLongAlphanumericString</di_ficustomer>
  <di_member_number>000000000</di_member_number>
  <access_token>aLongGeneratedAlphanumericString</access_token>
  <expires_in>1799</expires_in>
  <refresh_token>aLongGeneratedAlphanumericString</refresh_token>
  <refresh_token_expires_in>0</refresh_token_expires_in>
</token>



Lists of V1 and V2 API Proxies

Proxies requiring V1 oAuth Bearer Tokens (By Service Product and Endpoint):

Alerts and Messaging

  • Send Event - POST (/messagingservices/v1/fis/{di_fiid}/fiCustomers/{di_ficustomer}/events)
  • Get Destinations - GET (/destinations/v2/fis/{di_fiid}/products/{product_id}/notificationApps/{notification_app_id}/fiCustomers/{di_ficustomer}/destinations)
  • Create Destinations - POST (/destinations/v2/fis/{di_fiid}/products/{product_id}/notificationApps/{notification_app_id}/fiCustomers/{di_ficustomer}/destinations)
  • Update Destinations - PUT (/destinations/v2/fis/{di_fiid}/products/{product_id}/notificationApps/{notification_app_id}/fiCustomers/{di_ficustomer}/destinations)
  • Delete Destinations - DELETE (/destinations/v2/fis/{di_fiid}/products/{product_id}/notificationApps/{notification_app_id}/fiCustomers/{di_ficustomer}/destinations)
  • Delete Destination (single) - DELETE (/destinations/v2/fis/{di_fiid}/products/{product_id}/notificationApps/{notification_app_id}/fiCustomers/{di_ficustomer}/destinations)

Banking Services

  • Get FI Customer - GET (/bankingservices/v2/fis/{fiId}/fiCustomers/{fiCustomerId})

Customer

  • Register User (for Digital Banking) - POST (/registration/v4/fis/{di_fiid}/fiCustomers)

Proxies Requiring V2 oAuth Bearer Tokens (By Service Product & Endpoint):

Accounts

  • Get Accounts - GET /v1/accounts
  • Get Account - GET (/v1/accounts/{accountId})

Alerts and Messaging

  • Get Alert Preferences - GET (/v1/alert-preferences)
  • Get Alert Preference by ID - GET  (/v1/alert-preferences/{alertPreferenceId})
  • Create Alert Preference - POST (/v1/alert-preferences)
  • Update Alert Preference - PUT (/v1/alert-preferences/{alertPreferenceId})
  • Delete Alert Preference - DELETE (/v1/alert-preferences/{alertPreferenceId})
  • Get Alert Type - GET (/v1/alert-types)
  • Create Alert Type - POST (/v1/alert-types)
  • Update Alert Type - PUT (/v1/alert-types)
  • Delete Alert Type - DELETE (/v1/alert-types/{id})
  • Get Alert Templates - GET (/v1/alert-templates)
  • Create Alert Template - POST (/v1/alert-templates)
  • Update Alert Template - PUT (/v1/alert-templates)
  • Delete Alert Template - DELETE (/v1/alert-templates)
  • Get Alert History - GET (/v1/alert-history)
  • Get Alert History Content - GET (/v1/alert-history-content)

Banking Image Services

  • Get Images - GET (/v1/banking-images)
  • Get Image - GET (/v1/banking-images/{bankingImageId})

Disclosures

  • Get FI Disclosures - GET (/v1/institution-disclosures)
  • Create FI Disclosure - POST (/v1/institution-disclosures)
  • Update FI Disclosure - PUT (/v1/institution-disclosures/{institutionDisclosureId})
  • Get All User Accepted Disclosures - GET (/v1/institution-user-disclosures)
  • Create User Disclosure Acceptance - POST (/v1/institution-user-disclosures)
  • Update User Acceptance Disclosures - PUT (/v1/institution-user-disclosures)
  • Update User Acceptance Disclosure (by ID) - PUT (/v1/institution-user-disclosures/{institutionUserDisclosureId})
  • Delete User Acceptance Disclosure - DELETE (/v1/institution-user-disclosures)
  • Delete User Acceptance Disclosure (by ID)- DELETE (/v1/institution-user-disclosures/{institutionUserDisclosureId})

Money Movement

  • Create Transfer - POST (/v1/transfers)
  • Get Recipients - GET (/v1/recipients)
  • Get Recipient - GET (/v1/recipients/{recipientId})
  • Create Recipient - POST (/v1/recipients)
  • Update Recipient - PUT( /v1/recipients/{recipientId})
  • Delete Recipient - DELETE (/v1/recipients/{recipientId})

Transactions

  • Get Transactions - GET (/v1/transactions)


Getting Started

Candescent’s APIs support financial institutions worldwide. They can empower financial institutions and their partners to build valuable digital banking experiences.

It’s important to work with your Candescent representative to get officially onboarded to DevX for access to these APIs. Once onboarded, you’ll be able to implement your application, access shared and secret keys and begin testing the APIs.

After all the legal and compliance partnership agreements are in place, we'll set you up with your Authentication API client account. This will grant you access to a unique secret key that will be your ticket to the authentication API and staging and production environments.

The service available through the Candescent Digital Banking Developer Portal provides a token for the grant type:

Client Credentials

  • Used for trusted server-side applications
  • Sending a request passes a key-and-secret pair assigned to your application
  • Since the token is issued in the context of a Financial Institution (FI) rather than a user, no end-user login is required
  • Response provides the Bearer Token to be used to call other DevEx APIs

Steps to getting started:

  • Sign up and/or Login in for authentication

    To make your first API request, you'll need toself-register by clicking the Sign Up button. Then, click the link in your welcomeemail to verify your emailaddress.

  • Review API documentation and request postman collections

    Your Candescent representative will be able to email you the Postman collection for an API you are interested in. You may reach out directly or add the specific API to your favorites to alert your representative.
  • Test APIs in Postman

    In addition to the sample apps, a test drive environment is available to help you visualize the APIs. Using the JSONcollection and Postman, you’ll be able to see API requests working in action and view the information required to make them.

    This will also allow you to experience actual API behavior prior to beginning your integration. For a deeper dive into Postman, view additional reference material here.

Authentication

Authentication proves that you are who you say you are. Authentication tokens identify a user (the person using the app or site).

You‘ll need the following items to set up basic authentication:

Info Alert
Note
          Visit our guide on authentication to learn more.
  • Developer Hub account
  • Sandbox environment with an organization
  • Shared Key
  • Secret Key

Generating your Secret Key

You’ll need a bearer token or an API security key to authenticate API calls. A secret key serves as a secure token to authenticate and authorize requests. Unauthorized use of a secret key could potentially cause a security breach. Thes ecret key holds the error token used to access real data through the API.

Visit our guide on authentication  to learn more.

Before you begin, you‘ll require a unique client_id and client_secret for your app. Notify your implementation manager or PossibleNOW Support atsupport@possiblenow.com to request an OAuth client_id and client_secret. Include your My Preferences Client ID and the environment (staging (sandbox) or production) for which you want to generate the credentials in your request.

These credentials must be treated securely. 

    Use Cases & Examples

    All APIs require authorization token as header to get a successful response. OAuth2 token is used for authorization which is a standard industry-wide way of authorizing a call.

    Creates the bearer token for authorization

    • Get list of accounts GET /db-accounts/v1/accounts
    • Request -> Query Parameters:
      hostUserId: The specific identifier for that customer
    • Headers:
      Authorization: The bearer access token from the Authentication API
      TransactionId: A UUID string used as unique identifier for this token request

    Get the specified account for the given user

      • Get the accounts GET /db-accounts/v1/accounts/{accountId}
      • Request:
        Headers:
        Authorization: The access token from the Authentication APITransactionId: A UUID string used as unique identifier for this token request
        close

        Sign in now!

        Please sign up or sign in to add to watchlist

        Sign in
        close

        Added to watchlist!

        Your interest has been noted. An NCR Voyix Rep
        will contact you with further details soon.