Authentication overview

HERE Technologies API provides a suite of location-based services that require authentication to ensure secure access and track usage. Authentication is the process by which the API verifies the identity of the client (application or user) making a request. This process is crucial for managing access permissions, enforcing rate limits, and maintaining data integrity across the HERE platform. For developers, understanding the available authentication mechanisms is fundamental to integrating HERE services securely and efficiently into their applications.

The choice of authentication method depends on the application's architecture, security requirements, and the specific HERE API being accessed. Both client-side and server-side applications can implement robust authentication strategies. Proper credential management and adherence to security best practices are essential to prevent unauthorized access and protect sensitive data.

Supported authentication methods

HERE Technologies API supports two primary authentication methods: API Keys and OAuth 2.0. Each method is designed for different use cases and offers varying levels of security and flexibility.

API Keys

API Keys are simple, unique alphanumeric strings used to identify a project or application. They are suitable for applications where the security risk of exposing the key is manageable, such as client-side applications with strict referrer or IP restrictions, or simple server-side scripts. API keys are typically passed as a query parameter or in the request header.

  • When to use: Public client-side applications (e.g., web maps in a browser), quick prototyping, internal server-to-server communication where IP whitelisting is enforced.
  • Security considerations: API keys grant access to the associated project. If compromised, they can be used to make unauthorized requests, potentially incurring usage costs or accessing data.

OAuth 2.0

OAuth 2.0 is an industry-standard protocol for authorization that enables applications to obtain limited access to user accounts on an HTTP service, such as HERE APIs. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access that user account. This method is more complex to implement but offers significantly enhanced security, especially for applications handling sensitive user data or requiring granular access control.

  • When to use: Server-side applications, mobile applications, or any scenario requiring user consent, delegated authorization, or enhanced security features like token expiration and refresh. OAuth 2.0 is the recommended method for production-grade applications that require robust security. Further details on the OAuth 2.0 framework are available from the OAuth 2.0 specification.
  • Security considerations: OAuth 2.0 involves multiple flows (e.g., Authorization Code, Client Credentials) each suited for specific application types, minimizing direct exposure of credentials. Access tokens are short-lived, and refresh tokens are used to obtain new access tokens without re-authentication.

The following table summarizes the key characteristics of each authentication method:

Method When to Use Security Level Complexity
API Key Client-side web, simple server-side, prototyping Moderate (requires external restrictions) Low
OAuth 2.0 Server-side, mobile, user-centric apps, production environments High (token-based, delegated authorization) High

Getting your credentials

To obtain authentication credentials for HERE Technologies API, developers must register an account and create a project within the HERE Developer Portal. The process typically involves:

  1. Account Registration: Sign up for a developer account on the HERE Developer Portal.
  2. Project Creation: Once logged in, create a new project. Each project acts as a container for your applications and services, allowing you to manage credentials and track usage independently.
  3. Generating API Keys: For API Key authentication, navigate to your project settings, locate the 'API Keys' section, and generate a new key. You can often configure restrictions (e.g., HTTP referrer, IP address) directly within the portal to enhance security. Consult the HERE REST APIs documentation for specific instructions on key generation and management.
  4. Setting up OAuth 2.0 Credentials: For OAuth 2.0, you will typically need to register an application within your project. This involves providing details such as redirect URIs (for authorization code flow) and obtaining a Client ID and Client Secret. These credentials are used by your application to initiate the OAuth 2.0 flow.

It is crucial to store your credentials securely and follow the platform's guidelines for their use. Never hardcode sensitive credentials directly into client-side code or public repositories.

Authenticated request example

This section provides a basic example of an authenticated request using an API Key. While OAuth 2.0 involves more steps (obtaining an access token, then using it), an API Key example demonstrates the fundamental concept of including credentials in a request.

Consider a request to the HERE Geocoding and Search API using an API Key:

GET https://geocode.search.hereapi.com/v1/geocode?q=200+S+Mathilda+Sunnyvale+CA&apiKey={YOUR_API_KEY}

In this example, {YOUR_API_KEY} must be replaced with an actual API Key obtained from the HERE Developer Portal. The key is passed as a query parameter named apiKey. For production applications, especially those handling sensitive data, HERE often recommends using OAuth 2.0 for enhanced security and better credential management. Refer to the HERE Geocoding and Search API reference for detailed endpoint specifications and parameter requirements.

For OAuth 2.0, an authenticated request would typically involve including an Authorization header with a Bearer token:

GET https://geocode.search.hereapi.com/v1/geocode?q=200+S+Mathilda+Sunnyvale+CA
Authorization: Bearer {YOUR_ACCESS_TOKEN}

The {YOUR_ACCESS_TOKEN} is a short-lived token obtained through the OAuth 2.0 authorization flow, which authenticates the application and the user.

Security best practices

Implementing strong security measures is critical when working with any API, including HERE Technologies API. Adhering to best practices helps protect your application, user data, and prevents unauthorized access and potential service abuse.

  • Never embed API Keys directly in client-side code: For web applications, always restrict API keys by HTTP referrer (domain) to limit their use to your approved domains. For mobile applications, use platform-specific methods to obscure keys or consider a proxy server.
  • Use OAuth 2.0 for server-side and user-centric applications: OAuth 2.0 provides a more secure framework for delegated authorization, using short-lived access tokens and refresh tokens, reducing the risk of credential exposure.
  • Store credentials securely: API Keys, Client IDs, and Client Secrets should never be hardcoded or committed to version control systems like Git. Use environment variables, secret management services (e.g., AWS Secrets Manager, Google Secret Manager), or secure configuration files. More information on secure credential storage is available from AWS Secrets Manager documentation.
  • Implement IP whitelisting: For server-side API Key usage, restrict API key access to specific IP addresses or ranges that belong to your servers. This ensures that even if a key is compromised, it can only be used from authorized locations.
  • Rotate API Keys and OAuth Tokens regularly: Periodically generate new API keys and revoke old ones. Implement mechanisms to refresh OAuth tokens before they expire.
  • Monitor API usage: Regularly review your API usage logs within the HERE Developer Portal to detect unusual activity or potential unauthorized access. Set up alerts for unexpected spikes in usage.
  • Enforce HTTPS/TLS: Always ensure all communication with HERE APIs occurs over HTTPS (TLS). This encrypts data in transit, protecting credentials and data from interception. All HERE API endpoints support and enforce HTTPS.
  • Principle of Least Privilege: Grant only the necessary permissions to your API keys or OAuth clients. If an API key is only needed for geocoding, do not grant it access to routing services.
  • Error Handling: Implement robust error handling in your application to gracefully manage authentication failures, preventing information leakage or application crashes.