Three lines



User Access Token

The Uber API uses OAuth 2.0 to allow developers to get a user access token to access a single user’s data or do actions on their behalf. OAuth 2.0 is a specification outlined in RFC 6749 that allows third-party services to make requests on behalf of a user without accessing passwords and other sensitive information. If you are unfamiliar with OAuth 2.0, check out Aaron Parecki’s “OAuth 2 Simplified” guide.

To begin, register an application so that you can follow along with authenticating and making requests on the API in this guide.

We strongly recommend that you use a pre-built library to perform the authorization grant and token exchanges for OAuth 2.0. If you go this route, all you will need are the endpoints below and to specify your redirect URL in the application dashboard.

OAuth 2.0 endpoints

Authorization Host
Authorization Endpoint
Token Exchange Endpoint
Quickstart: Testing with a personal user access token

If you are trying out the Uber API for the first time, the quickest way to get an access token is by going to your application dashboard and following these steps:

  1. Select an existing application (or create a new one)
  2. Go to the Auth tab
  3. Select the scopes that you want to test with
  4. In the “Test with a Personal Access Token” module, click “Generate a new token”. The token generated will only be displayed once, and the token will be generated with the selected scopes from your Uber rider account that is signed into the dashboard.

The following steps go into detail about how to programmatically generate this user access token within your application.

Step 1: User authorizes your app

First, the user has to grant your app permission to access their data or do actions on their behalf. Uber provides an authorization page where users can securely sign in with their Uber username and password to grant permissions to your app. This authorization page is accessed through the authorization URL. To ensure that the driver grants permissions to your app properly, supply query parameters to that URL as described below.

Replace all <PLACEHOLDERS> below with the appropriate details.<CLIENT_ID>&response_type=code&redirect_uri=<REDIRECT_URI>
Parameter Description
response_type OAuth 2.0 response type. code is the only acceptable input at this time.
client_id The client ID of your application.
scope Space delimited list of grant scopes you would like to have permission to access on behalf of the user. If none is provided the default is the set selected in your application’s dashboard. It is invalid to provide no scopes and have none selected in the dashboard.
redirect_uri The URI we will redirect back to after an authorization by the resource owner. If none is provided the default is the first redirect URI provided in the dashboard.
state (optional) State which will be passed back to you to prevent tampering.

After you’ve supplied the needed parameters, present this authorization URL as a link for the user to visit. Usually, this link will say “Sign in with Uber”.

Step 2: Receive redirect

Once the Uber user authenticates and authorizes your app, Uber will issue an HTTP 302 redirect to the redirect_uri passed in Step 1 (or the first redirect URI in the dashboard if none was explicitly provided in Step 1). On that redirect, you will receive a single-use authorization code which expires in 10 minutes.

GET https://your-redirect-uri/?code=<AUTHORIZATION_CODE>

Note the code query param above, this is the authorization code you need for the next step.

Step 3: Get an access token

Use the Token Exchange endpoint to exchange the authorization code for an access_token which will allow you to make requests on behalf of the user.

Example Request:

Replace all <PLACEHOLDERS> with the appropriate details.

curl -F 'client_secret=<CLIENT_SECRET>' \
     -F 'client_id=<CLIENT_ID>' \
     -F 'grant_type=authorization_code' \
     -F 'redirect_uri=<REDIRECT_URI>' \
Parameter Description
client_id The Client ID of your application.
client_secret The Client Secret of your application.
grant_type In this step, this should be set to authorization_code.
redirect_uri The base of the URI must match the redirect_uri used during Step 1 above.
code The authorization code from Step 2: Receive Redirect.

Example Response:

    "access_token": "xxx",
    "token_type": "Bearer",
    "expires_in": 2592000,
    "refresh_token": "xxx",
    "scope": "profile history offline_access"

The access_token is valid for the time described by expires_in (in seconds). The refresh_token expires after one year and can be used to obtain a new access_token at any time given that your application is still authorized to access the API on behalf of this user.

The access_token retrieved from authenticating a user account will stay active even when a user changes the account password or other account details.

Step 4: Use bearer token

You can pass the access_token returned in the previous step as a bearer token in the Authorization header, or pass it in as a query parameter in the URL.

Example: OAuth token sent in a header

Replace <ACCESS_TOKEN> below with the token from Step 3.

curl -H "Authorization: Bearer <ACCESS_TOKEN>" \

Congratulations! You just learned how to generate a user access token and how to use that token to make requests to the API.

Refreshing tokens

If you requested the access token with the offline_access scope the response will include a refresh_token which can be used to refresh the access token. When the user’s access_token has expired, you can obtain a new access_token by exchanging the refresh_token associated with the access_token using the Token Exchange endpoint. Refreshing the user access token means that you don’t need to ask the user to authorize your app for the same permissions again (offline_access).

curl -F 'client_secret=<CLIENT_SECRET>' \
     -F 'client_id=<CLIENT_ID>' \
     -F 'grant_type=refresh_token' \
     -F 'refresh_token=<REFRESH_TOKEN>' \

A refresh_token is valid for one year and tokens that have been inactive for more than one year will be invalidated. The client ID must match the client ID from the authorization code flow.

Revoking tokens

There are two ways that a user access token can be revoked: either you revoke it yourself upon the user’s request, or the user can go to the Riders Profile page and click ‘Disconnect’ on your app.

Within your app’s interface, you may present the option of “disconnecting” a user’s Uber account from your app. Use the revoke endpoint to invalidate a user access token:

curl -F 'client_secret=<CLIENT_SECRET>' \
    -F 'client_id=<CLIENT_ID>' \
    -F 'token=<ACCESS_TOKEN>_TO_REVOKE>' \

A user can manually remove an app connections from the Riders Profile page. If a user removes your application, it will invalidate any existing tokens and your app will not be able to refresh any tokens. To gain access again, you will have to go through the entire flow from Step 1.

Common problems and solutions

Check out the GitHub guide on common OAuth errors.

Access token length: Expect that the length of access tokens may change over time as Uber makes changes to what is stored in them and how they are encoded. To account for this, please use a variable length data type without a specific maximum size to store access tokens and refresh tokens.

Error Code Description
invalid_request Required parameters were not provided.
invalid_client The client ID or secret provided is invalid.
invalid_grant Valid grant types are authorization_code and refresh_token
invalid_scope The scope parameter provided is not a valid subset of scopes.
server_error The server returned an unknown error.
temporarily_unavailable The endpoint is temporarily unable to respond.

Problem If you get {"error": "invalid_client"} then this means you are sending an additional HTTP request header which is not required but is validated by the Uber OAuth provider server. Another possible reason could be misspelled request parameter names.

Solution Remove the Authorization header from your request and try again, i.e. don’t send any HTTP request headers.

Problem If you have multiple redirect URLs defined in the Uber Developer Dashboard and you are making an authentication request without the redirect_uri parameter, the first redirect URL defined in the dashboard is used. If that first redirect URL doesn’t match the redirect URL you used in the Authorize step of the OAuth flow, you will get {"error": "access_denied"}. This error is raised even if the first redirect URL matches the redirect URL sent in the Authorize step.

Solution Send the redirect_uri parameter at each step of the OAuth flow.

Problem If you get {"error": "invalid_grant"} then this means the code inside the query parameter code has already been used once or has become invalid.

Solution Redo Step 1 in the OAuth flow to obtain a new authorization code and exchange for a new access token.

Problem If you get {"error": "invalid_grant"} when refreshing a token this means the refresh token being used is expired or has become invalid.

Solution Redo the Step 1 in the OAuth flow to obtain a new authorization code and exchange for a new access token.


© 2023 Uber Technologies Inc.