Authentication overview

OpenStreetMap (OSM) functions as a collaborative project for creating a free editable world map. Its authentication mechanisms are primarily designed to secure access to the OpenStreetMap API for actions that modify the map data, such as uploading changesets or interacting with user-specific data. For developers consuming OpenStreetMap data or utilizing services built upon it (like geocoding with Nominatim or routing engines), the authentication requirements depend on the specific service provider or the deployed instance, rather than a single, universal OSM authentication standard.

The core OpenStreetMap API, which allows users to read and write map data, employs OAuth 1.0a for authenticated requests. This standard provides a secure method for applications to access user data without requiring the user to share their credentials directly with the application. For read-only access to public OSM data, such as downloading raw map data or querying basic object details, authentication is generally not required, adhering to the project's open data principles. However, rate limits may apply to unauthenticated requests to prevent abuse of the API infrastructure.

Supported authentication methods

The OpenStreetMap API primarily supports OAuth 1.0a for actions requiring user authorization. Other methods may be used by third-party services that consume or process OSM data, but these are specific to those services.

The following table outlines the main authentication method for the core OpenStreetMap API:

Method When to Use Security Level
OAuth 1.0a
  • Uploading changesets to modify map data.
  • Accessing user-specific data (e.g., user preferences, private notes).
  • Creating or modifying OSM objects (nodes, ways, relations).
  • Applications requiring user consent for data modification.
High (industry standard for delegated authorization)
No Authentication
  • Read-only access to public map data (e.g., downloading .osm files, querying public object details).
  • Accessing OpenStreetMap's API v0.6 for public data.
N/A (no authorization required for public data)

OAuth 1.0a is a widely adopted authorization framework that allows a third-party application to obtain limited access to a user's protected resources on an HTTP service. The OAuth 1.0 specification outlines the process involving consumer keys, consumer secrets, request tokens, request token secrets, verifiers, access tokens, and access token secrets to establish secure communication and authorized access.

Getting your credentials

To obtain OAuth 1.0a credentials for the OpenStreetMap API, you must register your application. This process involves several steps:

  1. Create an OpenStreetMap Account: If you don't already have one, register for an account on the OpenStreetMap website.
  2. Register Your Application: Navigate to the My Settings > OAuth applications section of your OpenStreetMap profile.
  3. Provide Application Details: Fill out the required information for your application, including its name, description, website URL, and a callback URL. The callback URL is crucial for the OAuth flow, as it's where the user will be redirected after authorizing your application.
  4. Select Permissions: Define the scope of access your application requires. For example, specify if your application needs to read user preferences, modify map data, or upload GPX traces. Granting only necessary permissions adheres to the principle of least privilege.
  5. Receive Consumer Key and Secret: Upon successful registration, OpenStreetMap will provide you with a Consumer Key (also known as Client Key or API Key) and a Consumer Secret (also known as Client Secret). These are your application's unique identifiers and credentials for initiating the OAuth flow.

These consumer credentials are used to obtain a request token, which is then exchanged for an access token after the user authorizes your application. The access token and access token secret are used for all subsequent authenticated API calls on behalf of the user.

Authenticated request example

An authenticated request using OAuth 1.0a involves signing each request with your consumer credentials and the user's access token. While the specific implementation details vary by programming language and OAuth library, the general flow involves:

  1. Obtain Request Token: The application makes a request to the OpenStreetMap API's request token URL, signed with the Consumer Key and Secret.
  2. User Authorization: The user is redirected to the OpenStreetMap website to authorize the application. Upon authorization, OpenStreetMap redirects the user back to the application's callback URL with a verifier.
  3. Obtain Access Token: The application exchanges the request token and verifier for an access token and access token secret, signed with the Consumer Key and Secret.
  4. Make Authenticated API Call: Subsequent API calls (e.g., to upload a changeset) are signed using the Consumer Key, Consumer Secret, Access Token, and Access Token Secret. The signature typically includes details of the HTTP method, URL, and request parameters.

Here's a conceptual example of signing an API request using a generic OAuth 1.0a library (not specific to any single language, but illustrating the parameters):

POST /api/0.6/changeset/create HTTP/1.1
Host: api.openstreetmap.org
Authorization: OAuth oauth_consumer_key="your_consumer_key",
               oauth_token="your_access_token",
               oauth_signature_method="HMAC-SHA1",
               oauth_timestamp="1678886400",
               oauth_nonce="random_string",
               oauth_version="1.0",
               oauth_signature="generated_signature"
Content-Type: application/xml

<osm><changeset><tag k="comment" v="My first changeset"/></changeset></osm>

The Authorization header contains all the necessary OAuth parameters, including the dynamically generated oauth_signature. Libraries like Ruby's OAuth gem or Python's oauthlib handle the complex signing process automatically, simplifying development.

Security best practices

When working with OpenStreetMap authentication and handling user data, adhere to these security best practices:

  • Protect Your Credentials: Treat your Consumer Key, Consumer Secret, Access Token, and Access Token Secret as sensitive information. Never hardcode them directly into your application's source code. Instead, use environment variables, secure configuration files, or a secrets management service.
  • Use HTTPS Exclusively: All communication with the OpenStreetMap API should occur over HTTPS to encrypt data in transit and prevent eavesdropping. The OpenStreetMap API enforces HTTPS for all authenticated endpoints.
  • Least Privilege Principle: When registering your application, request only the minimum necessary permissions (scopes) required for its functionality. Avoid requesting broad access if your application only needs to perform specific actions. This limits the potential damage if your application's credentials are compromised.
  • Secure Callback URLs: Ensure your application's OAuth callback URL is secure and correctly configured. An improperly secured callback URL could be exploited for redirection attacks. Always use HTTPS for callback URLs.
  • Validate Signatures: If you are implementing OAuth 1.0a manually or using a library that requires explicit validation, ensure that you correctly validate the signatures of incoming requests (if your application acts as an OAuth service provider) to prevent tampering.
  • Error Handling and Logging: Implement robust error handling for authentication failures. Log authentication attempts and failures, but be careful not to log sensitive credentials. Monitoring these logs can help detect potential abuse or attacks.
  • Regularly Rotate Keys: While not a standard feature for OAuth 1.0a consumer keys, if your application uses API keys for other OpenStreetMap-related services, consider a strategy for regularly rotating these keys to minimize the impact of a compromise.
  • Stay Updated: Keep your OAuth libraries and dependencies updated to benefit from the latest security patches and improvements. Vulnerabilities in underlying libraries can expose your application to risks.