OpenStreetMap API Authentication: Methods & Security (2026)

Authentication overview

The OpenStreetMap (OSM) API serves as the interface for interacting with the OpenStreetMap database, enabling developers to read, add, modify, or delete geospatial data points. The authentication model distinguishes between read-only operations and write operations due to the nature of the collaborative, open-source project. Most read operations, which involve fetching map data like nodes, ways, or relations, typically do not require authentication, allowing broad public access to the platform's extensive dataset. This design facilitates widespread use of OSM data for various applications, including custom map rendering, geographic information system (GIS) analysis, and location-based services.

Conversely, any operation that modifies the OpenStreetMap database—such as creating new map features, updating existing ones, or uploading entire changesets—requires proper user authentication. This is crucial for maintaining data integrity, attributing changes to specific users, and preventing unauthorized modifications to the community-maintained map. The OpenStreetMap API employs OAuth 1.0a for these write operations, a standard protocol designed to allow third-party applications to access user data without exposing user credentials directly. This ensures that only authenticated and authorized users can contribute to the global map data.

Understanding this distinction is fundamental for developers integrating with the OpenStreetMap API. Applications focused solely on displaying map data or performing read-only queries can proceed without complex authentication setups. However, applications that aim to contribute back to the OpenStreetMap project or allow users to manage their OSM data must implement OAuth 1.0a to ensure secure and authorized interactions with the API.

Supported authentication methods

The OpenStreetMap API supports different authentication approaches based on the type of interaction an application performs with its data. The primary method for write operations is OAuth 1.0a.

OAuth 1.0a

OAuth 1.0a is primarily used for authenticating users who perform write operations on the OpenStreetMap database. This includes actions such as creating new nodes, ways, or relations, modifying existing geographic features, or uploading changesets. OAuth 1.0a provides a secure method for applications to obtain delegated authorization from an OpenStreetMap user without requiring the application to handle the user's login credentials directly. The process involves multiple steps:

1. Request Token: The consumer (your application) requests a temporary request token from the OpenStreetMap API.
2. User Authorization: The user is redirected to the OpenStreetMap website to authorize the consumer application, linking the request token to their user account.
3. Access Token: After user authorization, the consumer exchanges the authorized request token for a long-lived access token.

This access token, along with a secret, is then used to sign subsequent API requests, proving the application's and user's identity and authorization for write operations. More details on the OpenStreetMap OAuth implementation are available in the official documentation.

Unauthenticated Access

The OpenStreetMap API allows unauthenticated access for most read-only operations. This means applications can fetch map data, query existing features, and retrieve user profiles without needing to authenticate. This approach simplifies development for applications that only consume OpenStreetMap data, such as map viewers, routing services (that use OSM data), and data analysis tools. While unauthenticated, requests are still typically subject to API usage policies to prevent abuse and ensure fair resource distribution.

Summary of Authentication Methods

Getting your credentials

For applications requiring write access to the OpenStreetMap API, you will need to register your application to obtain OAuth 1.0a consumer keys and secrets. This process involves a few steps:

1. Create an OpenStreetMap Account: If you don't already have one, you need an OpenStreetMap user account to proceed. This account will be associated with your application registrations.
2. Register Your Application: Navigate to the "Register your application" page on the OpenStreetMap website. You will be prompted to provide several details about your application, including its name, description, and website URL. Crucially, you will need to specify a callback URL, which is where OpenStreetMap will redirect the user after they authorize your application.
3. Receive Consumer Key and Secret: Upon successful registration, OpenStreetMap will issue a Consumer Key (also known as Client ID) and a Consumer Secret (Client Secret). These two credentials are vital for initiating the OAuth 1.0a flow and should be treated as sensitive information. The consumer key identifies your application to the OpenStreetMap API, while the consumer secret is used to sign requests, verifying the authenticity of your application.

It is important to note that these credentials are specifically for your application as a consumer of the OpenStreetMap API. When a user authorizes your application, they are granting your application permission to act on their behalf, based on the scope of permissions you requested during the OAuth flow. For detailed instructions, refer to the OpenStreetMap Wiki on OAuth application registration.

Authenticated request example

Executing an authenticated request to the OpenStreetMap API for write operations involves using the OAuth 1.0a flow to obtain an access token and then signing subsequent requests. While the full multi-step OAuth dance is extensive, here's a conceptual example of a properly signed request after an access token (oauth_token and oauth_token_secret) has been obtained.

This example demonstrates updating a node's tags using an HTTP PUT request to the /api/0.6/node/{id} endpoint. The request must include an Authorization header generated using the OAuth 1.0a signature process.

Given:

• CONSUMER_KEY: Your application's consumer key
• CONSUMER_SECRET: Your application's consumer secret
• ACCESS_TOKEN: The user's OAuth access token
• ACCESS_TOKEN_SECRET: The user's OAuth access token secret
• NODE_ID: The ID of the node to update (e.g., 12345)
• CHANGESET_ID: The ID of the changeset this edit belongs to (e.g., 67890)

PUT /api/0.6/node/12345 HTTP/1.1
Host: api.openstreetmap.org
Content-Type: application/xml
Authorization: OAuth oauth_consumer_key="YOUR_CONSUMER_KEY",oauth_token="YOUR_ACCESS_TOKEN",oauth_signature_method="HMAC-SHA1",oauth_timestamp="CURRENT_TIMESTAMP",oauth_nonce="RANDOM_NONCE",oauth_version="1.0",oauth_signature="GENERATED_SIGNATURE"

<osm>
  <node id="12345" lat="52.5" lon="13.4" version="2" changeset="67890">
    <tag k="name" v="New Node Name"/>
    <tag k="amenity" v="restaurant"/>
  </node>
</osm>

The oauth_signature parameter in the Authorization header is the critical part. It is generated by applying a specific hashing algorithm (e.g., HMAC-SHA1) to a base string that includes the HTTP method, request URL, and all OAuth parameters, using both the consumer secret and access token secret as keys. Libraries in most programming languages are available to handle this OAuth request signing process. Developers should avoid implementing the signature generation manually to mitigate potential security vulnerabilities.

For unauthenticated read requests, the process is much simpler, typically involving a direct HTTP GET request without any Authorization header.

GET /api/0.6/node/12345 HTTP/1.1
Host: api.openstreetmap.org

This request would retrieve the XML representation of the node with ID 12345 without requiring any authentication.

Security best practices

Adhering to security best practices is crucial when integrating with the OpenStreetMap API, especially for applications performing write operations. These practices help protect user data, maintain the integrity of the OpenStreetMap database, and ensure your application remains secure.

Protecting Consumer and Access Secrets

• Environment Variables/Secret Management: Never hardcode your OAuth Consumer Secret or Access Token Secrets directly into your application's source code. Store them securely using environment variables, dedicated secret management services (e.g., AWS Secrets Manager, Google Secret Manager), or secure configuration files that are excluded from version control.
• Server-Side Storage: Access Tokens and their secrets should always be stored on your server-side infrastructure, not client-side (e.g., in a web browser's local storage or a mobile app's client-side code). Client-side storage exposes these credentials to potential interception or compromise.
• Secure Transmission: Always use HTTPS for all communications with the OpenStreetMap API to encrypt data in transit, protecting your credentials and sensitive map data from eavesdropping.

Implementing OAuth 1.0a Correctly

• Use Libraries: Do not attempt to implement the OAuth 1.0a signing process manually. Use well-vetted, official OAuth libraries for your chosen programming language. These libraries handle the complexities of nonce generation, timestamping, request parameter ordering, and signature generation, significantly reducing the risk of implementation errors that could lead to vulnerabilities.
• Callback URL Validation: Ensure your application's registered callback URLs are specific and secure. OpenStreetMap uses this URL to redirect users after authorization, and a misconfigured URL could lead to credential leakage.
• Token Expiration and Revocation: While OAuth 1.0a access tokens are often long-lived, be prepared to handle token revocation by the user or OpenStreetMap. Implement mechanisms to re-authenticate or prompt the user for re-authorization if an access token becomes invalid.

Rate Limiting and Abuse Prevention

• Respect API Usage Policies: Be mindful of the OpenStreetMap API usage policies. Excessive requests, especially write operations, can lead to your application being temporarily or permanently blocked. Implement appropriate rate limiting within your application to prevent accidental abuse.
• Input Validation: Before submitting any data to the OpenStreetMap API, rigorously validate all user-generated input. This prevents malicious data injection or malformed data that could corrupt the OpenStreetMap database.

Regular Security Audits

• Code Reviews: Periodically review your application's code for any potential security weaknesses, especially regarding how credentials are handled and API requests are signed.
• Stay Updated: Keep your OAuth libraries and underlying application frameworks updated to benefit from the latest security patches and improvements.

By following these best practices, developers can build secure and responsible applications that interact effectively with the OpenStreetMap API, contributing positively to the open data ecosystem while protecting user and system integrity.