Authentication overview

Nordigen's authentication framework is designed to facilitate secure and compliant access to financial data through its Account Information and Premium Data APIs. The system primarily relies on a two-step process: initial authentication using API keys to obtain an access token, followed by the use of this token to authorize subsequent API requests. For operations requiring end-user consent, particularly when accessing bank accounts under Open Banking regulations, Nordigen integrates with the OAuth 2.0 authorization framework. This approach ensures that applications can securely interact with Nordigen's services while maintaining user privacy and adhering to regulatory compliance such as GDPR.

The authentication flow typically involves an application exchanging its unique API key and client secret for an access token. This token, which has a limited lifespan, must then be included in the Authorization header of all subsequent API requests. For Open Banking specific flows, the application must redirect the end-user to their bank's authentication portal, obtain explicit consent, and then exchange an authorization code for an access token, as defined by the OAuth 2.0 Authorization Framework. This layered security model protects both the developer's credentials and the end-user's financial data.

Supported authentication methods

Nordigen supports two primary authentication mechanisms:

  1. API Keys: Used to authenticate the application itself with Nordigen's platform, primarily for obtaining access tokens and managing resources like agreements and requisitions.
  2. OAuth 2.0: Essential for securing access to end-user financial data, requiring explicit consent from the user via their bank's authentication system. This is crucial for compliance with Open Banking regulations and GDPR.

The following table details the application and security level of each method:

Method When to Use Security Level
API Key Generating access tokens, managing developer-side resources (e.g., requisitions, agreements) before user interaction. High (requires secure storage and transmission)
OAuth 2.0 Obtaining end-user consent for accessing bank account information, initiating bank redirects, and securely retrieving financial data. Very High (delegated authorization, user-centric control)

For most integrations, both methods are used in conjunction: API keys to authenticate your application with Nordigen, and OAuth 2.0 to handle the end-user's interaction with their bank and grant consent for data access. All communication with Nordigen's API endpoints must occur over HTTPS/TLS to ensure data encryption in transit, irrespective of the authentication method used.

Getting your credentials

To begin authenticating with Nordigen, you need to obtain your API key and client secret from the Nordigen dashboard. Follow these steps:

  1. Create a Nordigen account: If you haven't already, sign up for a free account on the Nordigen homepage.
  2. Access the Dashboard: Log in to your Nordigen developer dashboard.
  3. Navigate to API Keys: Locate the section related to API keys or credentials within your dashboard settings. Nordigen refers to these as your 'secret ID' and 'secret key' within the quickstart documentation.
  4. Generate/Retrieve Credentials: Your dashboard will display your unique Secret ID (Client ID) and Secret Key (Client Secret). These are critical for generating Nordigen access tokens.

It is important to treat your Secret ID and Secret Key as sensitive information. They should never be hardcoded into client-side applications, publicly exposed in version control, or shared insecurely. Upon obtaining these credentials, refer to the Nordigen API reference for token generation to understand how to exchange them for a temporary access token.

Authenticated request example

The first step in making an authenticated request to Nordigen's API is obtaining an access token. This is typically done by sending your client ID and client secret to the /token/new/ endpoint. Once you have an access token, you can use it in the Authorization header of subsequent requests.

Step 1: Obtain an Access Token

This example demonstrates how to get an access token using Python, as detailed in the Nordigen Python quickstart guide:


import requests
import json

client_id = "YOUR_SECRET_ID"  # Replace with your actual Secret ID
client_secret = "YOUR_SECRET_KEY" # Replace with your actual Secret Key

url = "https://nordigen.com/api/v2/token/new/"
headers = {
    "Content-Type": "application/json"
}
data = {
    "secret_id": client_id,
    "secret_key": client_secret
}

response = requests.post(url, headers=headers, data=json.dumps(data))

if response.status_code == 200:
    token_data = response.json()
    access_token = token_data.get("access")
    refresh_token = token_data.get("refresh")
    access_expires = token_data.get("access_expires")
    print(f"Access Token: {access_token}")
    print(f"Refresh Token: {refresh_token}")
    print(f"Access Expires In: {access_expires} seconds")
else:
    print(f"Error obtaining token: {response.status_code} - {response.text}")

This request returns an access token (used for API calls), a refresh token (used to get new access tokens once the current one expires), and the access_expires duration in seconds.

Step 2: Use the Access Token for API Requests

After acquiring the access token, it must be included in the Authorization header of all subsequent API requests, prefixed with Bearer. For example, to retrieve a list of institutions:


# Assume 'access_token' has been obtained from Step 1

url = "https://nordigen.com/api/v2/institutions/?country=GB"
headers = {
    "Authorization": f"Bearer {access_token}",
    "accept": "application/json"
}

response = requests.get(url, headers=headers)

if response.status_code == 200:
    institutions = response.json()
    print("Available Institutions:")
    for institution in institutions:
        print(f"- {institution['name']} ({institution['id']})")
else:
    print(f"Error fetching institutions: {response.status_code} - {response.text}")

This pattern applies to all Nordigen API endpoints that require authentication. The access token typically has a limited validity period (e.g., 24 hours), after which it must be refreshed using the refresh_token at the /token/refresh/ endpoint to obtain a new access token without re-authenticating with your client ID and secret.

Security best practices

When implementing Nordigen authentication, adherence to security best practices is crucial to protect both your application and your users' financial data.

  • Secure Storage of Credentials: Never hardcode your Nordigen Client ID and Client Secret directly into your source code, especially for public repositories. Use environment variables, secure configuration files, or secret management services (e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) to store these credentials. This prevents exposure if your code repository is compromised.
  • Server-Side Authentication: Perform all token generation and access token refresh operations on your server-side application. Exposing your Client ID and Client Secret in client-side code (e.g., JavaScript in a web browser) makes them vulnerable to interception and misuse. The OAuth 2.0 official documentation emphasizes server-side flows for confidential clients.
  • HTTPS Everywhere: Ensure all communication with Nordigen's API — including token requests and data retrieval — uses HTTPS. This encrypts data in transit, protecting your credentials and sensitive financial information from eavesdropping.
  • Token Expiration and Refresh: Nordigen access tokens have a limited lifespan. Implement a mechanism to handle token expiration gracefully by using the provided refresh token to obtain a new access token before the current one expires. Store refresh tokens securely, similar to how you store your client secret.
  • Error Handling and Logging: Implement robust error handling for authentication failures. Avoid logging sensitive information (like API keys or full access tokens) in plain text in application logs. Log only necessary details for debugging, such as the type of error and a correlation ID.
  • Least Privilege Principle: Configure API access with the minimum necessary permissions. While Nordigen's API keys typically grant broad access to your account, ensure that any internal systems or microservices interacting with Nordigen only have access to the specific credentials and functionalities they require.
  • Regular Security Audits: Periodically review your application's authentication implementation and credential storage practices. Stay informed about security updates from Nordigen and general API security best practices.
  • Protect Redirect URIs (for OAuth 2.0): For OAuth 2.0 flows, carefully configure and validate your redirect URIs in the Nordigen dashboard. Only allow whitelisted URLs to receive authorization codes to prevent redirection attacks.