Authentication overview
Sabre for Developers utilizes industry-standard authentication protocols to secure access to its extensive suite of travel APIs. The primary mechanism for API authentication is OAuth 2.0, which facilitates secure delegated access to protected resources. This approach ensures that applications can access Sabre APIs on behalf of a user or themselves without exposing sensitive user credentials directly to the client application.
OAuth 2.0 operates by issuing access tokens, which are temporary credentials that grant specific permissions. When an application needs to interact with a Sabre API, it first obtains an access token through an authorization flow. This token is then included in subsequent API requests. The use of tokens enhances security by limiting the scope and duration of access, and by allowing tokens to be revoked without invalidating the user's primary credentials. For a general understanding of OAuth 2.0 flows, the OAuth 2.0 specification provides detailed information.
Sabre's implementation of OAuth 2.0 supports different grant types tailored to various application architectures, including server-to-server integrations and client-side applications. The choice of grant type depends on the application's nature and its ability to securely store client credentials. All authentication processes are managed through Sabre's identity and access management system, which issues and validates tokens against registered applications.
Supported authentication methods
Sabre for Developers primarily supports OAuth 2.0 for authenticating API requests. Within the OAuth 2.0 framework, specific grant types are recommended based on the integration scenario. These methods are designed to provide varying levels of security and operational convenience for different types of applications interacting with the Sabre APIs. The table below outlines the core authentication methods and their typical use cases.
| Method | When to Use | Security Level |
|---|---|---|
| OAuth 2.0 Client Credentials Grant | Server-to-server applications, backend services, batch processes where there is no end-user involvement. The application authenticates itself. | High. Client ID and Client Secret are exchanged directly with the authorization server. |
| OAuth 2.0 Authorization Code Grant | Web applications where an end-user grants permission for the application to act on their behalf. Involves a redirect to Sabre's authorization server. | High. Client Secret is kept confidential on the server, and authorization codes are exchanged for tokens. |
| OAuth 2.0 Password Grant (Legacy/Limited Use) | Not generally recommended for new integrations due to security implications. Used in trusted first-party applications where the user provides credentials directly to the application. | Moderate. Requires handling user credentials directly, increasing risk if not implemented carefully. Sabre's documentation recommends alternative grants. |
For most integrations, the Client Credentials Grant is suitable for applications that operate independently of a specific user session, while the Authorization Code Grant is preferred for applications that require user consent and act on behalf of a user. Sabre's authentication and security guides provide detailed implementation steps for each grant type.
Getting your credentials
To begin authenticating with Sabre for Developers APIs, you need to obtain API credentials. The process typically involves registering your application within the Sabre Dev Studio portal. For initial development and testing, you can register for a free Sabre Dev Studio account, which provides access to a sandbox environment.
- Register for a Sabre Dev Studio Account: Navigate to the Sabre for Developers portal and sign up for an account. This provides access to the developer console and documentation.
- Create a New Application: Within your developer account, create a new application. During this process, you will typically define your application's name, description, and potentially callback URLs if using the Authorization Code Grant.
- Retrieve Client ID and Client Secret: Upon successful application creation, Sabre will issue a Client ID and a Client Secret. These are your primary credentials for authenticating with the OAuth 2.0 server.
- API Key (if applicable): Some legacy APIs or specific services may still utilize API keys in conjunction with or instead of OAuth tokens. Always refer to the specific API reference documentation for the exact authentication requirements of the endpoint you intend to use.
- Production Access: For production environments, a commercial agreement with Sabre and a certification process are generally required. This typically involves a more rigorous review of your application's security and functionality to ensure compliance with Sabre's operational standards, including PCI DSS compliance for handling sensitive payment data.
It is crucial to store your Client Secret securely and never embed it directly in client-side code or public repositories. Treat your credentials with the same level of security as you would a password.
Authenticated request example
This example demonstrates how to obtain an access token using the OAuth 2.0 Client Credentials Grant and then use that token to make an authenticated API request to a Sabre API. This flow is common for server-to-server integrations.
Step 1: Obtain an Access Token
First, make a POST request to Sabre's authentication endpoint to exchange your Client ID and Client Secret for an access token. The exact endpoint may vary between sandbox and production environments.
curl -X POST \
'https://api.sabre.com/v2/auth/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'Authorization: Basic <Base64EncodedClientID:ClientSecret>' \
-d 'grant_type=client_credentials'
Replace <Base64EncodedClientID:ClientSecret> with the Base64 encoded string of your Client ID followed by a colon and your Client Secret (e.g., echo -n "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" | base64).
A successful response will return a JSON object containing the access token and its expiration time:
{
"access_token": "T1RLAQI...",
"token_type": "bearer",
"expires_in": 3600
}
Step 2: Make an Authenticated API Request
Once you have the access_token, include it in the Authorization header of your subsequent API requests as a Bearer token.
curl -X GET \
'https://api.sabre.com/v1/lists/airports?offset=1&limit=10' \
-H 'Authorization: Bearer <YOUR_ACCESS_TOKEN>'
Replace <YOUR_ACCESS_TOKEN> with the token received in the previous step. This example fetches a list of airports. The specific API endpoint and parameters will depend on the Sabre service you are consuming. Refer to the Sabre API references for details on specific endpoints and their requirements.
Security best practices
Adhering to security best practices is essential when integrating with Sabre APIs to protect your application, user data, and maintain the integrity of the travel ecosystem. Sabre's developer guidelines emphasize several key areas:
- Protect Client Credentials: Your Client ID and Client Secret are sensitive. Store them securely, ideally in environment variables or a secure configuration management system, and never hardcode them directly into your application's source code, especially for client-side applications. Do not commit them to version control systems.
- Secure Token Storage: Access tokens should be stored in memory or in a secure, encrypted storage mechanism for the duration of their validity. Avoid storing them in insecure locations like local storage (for browser-based applications) without proper protections.
- Token Expiration and Refresh: Implement logic to handle token expiration. Access tokens have a limited lifespan (e.g., 3600 seconds). Your application should be able to detect an expired token and request a new one using the appropriate OAuth 2.0 flow (e.g., refresh token if applicable, or re-authenticate).
- HTTPS/TLS Everywhere: Always use HTTPS for all communications with Sabre APIs and your own backend services. This encrypts data in transit, preventing eavesdropping and tampering. Sabre APIs enforce HTTPS.
- Input Validation and Sanitization: Validate all input received from users and external systems before processing it or passing it to Sabre APIs. Sanitize input to prevent common vulnerabilities like SQL injection or cross-site scripting (XSS) if your application processes user-generated content.
- Error Handling and Logging: Implement robust error handling to gracefully manage API failures or authentication issues. Log relevant security events, such as failed authentication attempts, but avoid logging sensitive data like credentials or full access tokens.
- Least Privilege Principle: Request only the minimum necessary permissions (scopes) when obtaining an access token. This limits the potential impact if a token is compromised.
- Regular Security Audits: Periodically review your application's security posture, including code audits, vulnerability scanning, and penetration testing, especially before deploying to production.
- Stay Updated: Keep your application's libraries, frameworks, and Sabre API integrations up to date to benefit from the latest security patches and features. Refer to the Sabre Developer Guides for the latest security recommendations and API updates.