Authentication overview

Amadeus for Developers provides secure access to its suite of travel APIs through established authentication protocols. These mechanisms ensure that only authorized applications can interact with the Amadeus platform, protecting both the developer's application and the underlying travel data. The choice of authentication method depends on the specific API being accessed and the nature of the application being developed, ranging from simple server-side integrations to complex client-side applications requiring user consent.

The primary goal of Amadeus for Developers's authentication framework is to offer a balance between ease of use for developers and the stringent security requirements of the travel industry. Developers are guided through the process of obtaining and managing credentials, with clear instructions on how to implement them across various programming languages and application architectures. This structured approach helps maintain data integrity and user privacy in accordance with regulations such as GDPR compliance information.

For most self-service API calls, a combination of a Client ID and Client Secret, obtained through the developer portal, is sufficient. These credentials are used to request an access token, which then authorizes subsequent API requests. For scenarios involving user data or third-party applications, Amadeus for Developers implements the OAuth 2.0 framework, which provides a delegated authorization flow without sharing user credentials directly with the application, as detailed by the OAuth 2.0 specification.

Supported authentication methods

Amadeus for Developers primarily supports two authentication methods for accessing its APIs:

  1. API Key (Client ID & Client Secret): This method is suitable for server-side applications where credentials can be securely stored. It involves exchanging your Client ID and Client Secret for an access token.
  2. OAuth 2.0: This protocol is used for applications that need to access user-specific data or require delegated authorization. It involves a more complex flow where users grant permission to an application without sharing their credentials directly.

Comparison of Authentication Methods

Method When to Use Security Level
API Key (Client ID & Client Secret) Server-side applications, backend services, personal tools where credentials can be securely stored and are not exposed to end-users. Ideal for direct API calls from a trusted environment. Moderate to High. Security depends heavily on proper storage and handling of the Client Secret on the server. Requires careful management to prevent exposure.
OAuth 2.0 Client-side applications (web, mobile), third-party integrations, applications requiring user consent to access their data, or scenarios where delegated authorization is necessary. Prevents client applications from handling user credentials directly. High. Designed for delegated authorization, minimizing credential exposure. Relies on secure redirection and token exchange. Adheres to the OAuth 2.0 Authorization Framework.

For both methods, the general flow involves obtaining an access token from an authentication server. This token is then included in the Authorization header of subsequent API requests. Access tokens typically have a limited lifespan and must be refreshed periodically to maintain continuous access. Amadeus for Developers provides specific endpoints for token generation and refresh, which are detailed in their API authentication guide.

Getting your credentials

To begin using Amadeus for Developers APIs, you need to register an application and obtain your credentials. This process is managed through the Amadeus for Developers self-service portal:

  1. Create an Amadeus for Developers Account: If you don't already have one, sign up on the Amadeus for Developers registration page.
  2. Access the Developer Console: Log in to your account and navigate to the developer console or dashboard.
  3. Create a New Application: Within the console, you will find an option to create a new application. Provide a name and a brief description for your application.
  4. Retrieve Client ID and Client Secret: Upon successful creation, the system will generate a unique Client ID and Client Secret for your application. These are your primary credentials for API key-based authentication.
  5. Configure Redirect URIs (for OAuth 2.0): If your application will use OAuth 2.0, you must configure the authorized redirect URIs in your application settings within the developer console. These URIs are where Amadeus will redirect the user after they have granted or denied access to your application. This is a critical security measure to prevent phishing and ensure tokens are sent only to trusted destinations, as emphasized by Google's OAuth 2.0 documentation on redirect URIs.

It is important to treat your Client Secret with the same level of confidentiality as a password. Never embed it directly in client-side code (e.g., JavaScript in a browser, mobile app binaries) where it can be easily extracted. For server-side applications, store it in environment variables or a secure configuration management system rather than hardcoding it.

Authenticated request example

Once you have your Client ID and Client Secret, the first step is to obtain an access token. Here's an example using Python to get an access token and then make a simple API request. This example assumes you have replaced YOUR_CLIENT_ID and YOUR_CLIENT_SECRET with your actual credentials.

Step 1: Get an Access Token (Python)


import requests
import os

CLIENT_ID = os.environ.get('AMADEUS_CLIENT_ID')
CLIENT_SECRET = os.environ.get('AMADEUS_CLIENT_SECRET')

TOKEN_URL = 'https://test.api.amadeus.com/v1/security/oauth2/token'

headers = {
    'Content-Type': 'application/x-www-form-urlencoded'
}
data = {
    'grant_type': 'client_credentials',
    'client_id': CLIENT_ID,
    'client_secret': CLIENT_SECRET
}

try:
    response = requests.post(TOKEN_URL, headers=headers, data=data)
    response.raise_for_status() # Raise an exception for HTTP errors
    token_data = response.json()
    access_token = token_data['access_token']
    print(f"Access Token: {access_token}")
except requests.exceptions.RequestException as e:
    print(f"Error obtaining token: {e}")
    access_token = None

This Python code snippet demonstrates fetching an access token from the Amadeus authentication server. It uses the requests library to send a POST request to the token endpoint, providing the grant type, client ID, and client secret. It's crucial to retrieve CLIENT_ID and CLIENT_SECRET from environment variables for security, rather than embedding them directly in the code.

Step 2: Make an Authenticated API Request (Python)

With the access token, you can now make authenticated calls to Amadeus APIs. The token must be included in the Authorization header as a Bearer token.


if access_token:
    FLIGHT_SEARCH_URL = 'https://test.api.amadeus.com/v2/shopping/flight-offers'
    
    api_headers = {
        'Authorization': f'Bearer {access_token}'
    }
    
    params = {
        'originLocationCode': 'SYD',
        'destinationLocationCode': 'BKK',
        'departureDate': '2024-12-01',
        'adults': 1
    }

    try:
        flight_response = requests.get(FLIGHT_SEARCH_URL, headers=api_headers, params=params)
        flight_response.raise_for_status() # Raise an exception for HTTP errors
        flight_data = flight_response.json()
        print("Flight Offers:")
        # Process flight_data
        if 'data' in flight_data and flight_data['data']:
            for offer in flight_data['data'][:3]: # Print first 3 offers
                print(f"  Price: {offer['price']['grandTotal']} {offer['price']['currency']}")
                print(f"  Segments: {len(offer['itineraries'][0]['segments'])}")
        else:
            print("  No flight offers found for the given criteria.")
    except requests.exceptions.RequestException as e:
        print(f"Error making API request: {e}")
else:
    print("Cannot make API request without an access token.")

This second Python snippet demonstrates how to use the obtained access_token to query the Flight Offers Search API. The token is prefixed with Bearer and added to the Authorization header. This is a common pattern for Bearer Token usage in HTTP authentication, ensuring that the request is authorized. The example also includes basic error handling and prints some details from the API response.

Security best practices

Adhering to security best practices is essential when integrating with Amadeus for Developers APIs to protect your application, user data, and maintain the integrity of the travel ecosystem:

  • Protect Your Client Secret: Your Client Secret should be treated as a highly sensitive credential. Never hardcode it directly into your application's source code, especially for client-side applications (web browsers, mobile apps). Instead, use environment variables, secure configuration files, or a secrets management service. For server-side applications, ensure that access to these files or variables is restricted.
  • Use HTTPS for All Communications: Always ensure that all communication with Amadeus for Developers APIs, including token requests and API calls, occurs over HTTPS. This encrypts data in transit, protecting credentials and sensitive travel information from eavesdropping and tampering.
  • Securely Store Access Tokens: While access tokens have a limited lifespan, they still grant access to resources. Store them securely, preferably in memory for the duration of their validity, rather than persisting them to disk unnecessarily. If persistence is required, ensure it's encrypted.
  • Implement Token Refresh Mechanisms: Access tokens expire. Implement a robust mechanism to refresh tokens before they expire to maintain uninterrupted API access. Amadeus for Developers provides endpoints for refreshing tokens, which typically involve using a refresh token (if applicable to the OAuth flow you're using) or re-requesting a new access token with your client credentials.
  • Validate Redirect URIs (OAuth 2.0): For OAuth 2.0 flows, meticulously configure and validate your redirect URIs in the Amadeus for Developers console. Only allow redirects to URIs that you control and trust. This prevents malicious actors from intercepting authorization codes or tokens.
  • Least Privilege Principle: Request only the minimum necessary permissions for your application. If an API key is sufficient for your use case, avoid implementing more complex OAuth 2.0 flows that might expose more data than needed.
  • Error Handling and Logging: Implement comprehensive error handling for authentication failures and API errors. Log relevant information for debugging, but be cautious not to log sensitive data like Client Secrets or full access tokens.
  • Regular Credential Rotation: Periodically rotate your Client Secrets. This reduces the risk associated with a compromised credential, as old secrets will become invalid after rotation. Amadeus for Developers may offer tools in their console to facilitate this.
  • Monitor API Usage: Regularly monitor your API usage and look for unusual patterns that might indicate unauthorized access or abuse. The Amadeus for Developers console typically provides dashboards for this purpose.

By following these best practices, developers can significantly enhance the security posture of their applications integrating with Amadeus for Developers, thereby protecting their users and maintaining compliance with data protection standards.