¶ Overview

This documentation provides detailed guidance on integrating the Uber OAuth authorization code flow, enabling partners to securely initiate subsequent API calls to Uber services.

¶ OAuth Authorization Code Flow

¶ Step 1 - OAuth /authorize request and response

Request Details:

• HTTP Method: GET
• Domain: auth.uber.com
• Path: /oauth/v2/authorize

Query Params	Description
client_id	Your application’s client ID
response_type	Must be set to code for the authorization code flow
redirect_uri	The redirect URI registered for your application
scope	Space-delimited list of requested scopes
state	State value, described in Appendix: State Parameter in OAuth Requests
nonce	Required when requesting openid; random value echoed in id_token

Example Request from browser:

https://auth.uber.com/oauth/v2/authorize?client_id=<your_client_id>&response_type=code&redirect_uri=<your_client_redirect_uri>&scope=<space-delimited-scope>&state=<your_state>&nonce=<your_nonce>

Note: Make sure to replace the placeholder by the actual value for

• client_id
• redirect_uri
• scope
• state

Example Response:

HTTP Status Code 302 Found
Location: <your_client_redirect_uri>?code=<authorization_code>&state=<your_state>

¶ Step 2 - OAuth /token request and response

Request Details:

• HTTP Method: POST
• Domain: auth.uber.com
• Path: /oauth/v2/token
• Content-Type: application/x-www-form-urlencoded (Form Body)

Form Body	Description
client_id	Your application’s client ID
client_secret	Your application’s client secret
redirect_uri	The redirect URI registered for your application
scope	Space-delimited list of requested scopes (optional)
grant_type	Must be set to authorization_code
code	Authorization code returned in Step 1

Example Request:

curl -X POST 'https://auth.uber.com/oauth/v2/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=<client_id>' \
  --data-urlencode 'client_secret=<client_secret>' \
  --data-urlencode 'redirect_uri=<partner_redirect_uri>' \
  --data-urlencode 'grant_type=authorization_code' \
  --data-urlencode 'code=<AUTHORIZATION_CODE_FROM_STEP_1>'

Example Response:

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": 2592000,
  "refresh_token": "<refresh_token>",
  "scope": "offline_access profile profile.mobile_number"
}

_{As the example above, the Uber issued access token lasts 30 days.}

¶ Call Uber Resource API call using the retrieved token from OAuth flow

¶ Get User Profile as the example

Request Details:

• HTTP Method: GET
• Domain: api.uber.com
• Path: /v1.2/me

HTTP Header	Description
Authorization	Bearer <ACCESS_TOKEN_FROM_STEP_2>

Example Request:

curl 'https://api.uber.com/v1.2/me' \
  -H 'Authorization: Bearer <ACCESS_TOKEN_FROM_STEP_2>'

Example Response:

{
  "uuid": "",
  "rider_id": "<unique_uber_user_identifier>",
  "first_name": "<first_name>",
  "last_name": "<last_name>",
  "email": "<email_address>",
  "picture": "<profile_picture_url>",
  "promo_code": "<uber_promo_code>",
  "mobile_verified": <true | false>,
  "mobile_number": "<mobile_number>"
}

_{Note: The uuid field may be empty. Use rider_id as the unique Uber user identifier.}

¶ [For Testing Only] Re-test Uber OAuth Consent Page

In step one, users will be prompted to complete login/signup and consent. Note that the user only needs to consent once for a specific client and the requested scopes. During development, if you want to prompt users to consent again, you can add the additional query param prompt=consent to the /authorize request.

Request Details:

• HTTP Method: GET
• Domain: auth.uber.com
• Path: /oauth/v2/authorize

Additional Query Param	Description
prompt	Set to consent to force showing the consent screen again during development.

Example Request from browser:

https://auth.uber.com/oauth/v2/authorize?client_id=<your_client_id>&response_type=code&redirect_uri=<your_client_redirect_uri>&scope=<space-delimited-scope>&state=<your_state>&prompt=consent

Note: Make sure to replace the placeholder by the actual value for

• client_id
• redirect_uri
• scope
• state

¶ Refresh Token Flow

After completing the initial authorization code flow, the response includes both an access token and a refresh token. The access token is valid for 30 days. Once it expires, the refresh token can be used to obtain a new access token without requiring the user to go through the Uber OAuth flow again.

Request Details:

• HTTP Method: POST
• Domain: auth.uber.com
• Path: /oauth/v2/token

Form Body	Description
client_id	Your application’s client ID
client_secret	Your application’s client secret
grant_type	Must be set to refresh_token
refresh_token	Refresh token issued together with access token

Example Request:

curl -X POST 'https://auth.uber.com/oauth/v2/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=<client_id>' \
  --data-urlencode 'client_secret=<client_secret>' \
  --data-urlencode 'grant_type=refresh_token' \
  --data-urlencode 'refresh_token=<REFRESH_TOKEN_FROM_STEP_2>'

Example Response:

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": 2592000,
  "refresh_token": "<refresh_token>",
  "scope": "profile profile.mobile_number offline_access"
}

_{Note: The scope value shown is an example.}

¶ ID Token (OpenID Connect)

If the openid scope is requested during the OAuth flow, the /oauth/v2/token response includes an id_token (a signed JWT) in addition to the access token.

• The id_token represents the authenticated user’s identity and profile claims.
• Retrieve the signing key via JWKS at https://auth.uber.com/oauth/v2/certs. Use the kid from the id_token header to select the correct key. Cache keys for only a short period of time and refetch when either cache is expired or an unknown kid is encountered.
• Validate the id_token:
  • Signature algorithm (e.g., RS256) and signature using JWKS
  • iss equals https://auth.uber.com
  • aud contains your client_id (and azp if multiple audiences are present)
  • exp and iat within acceptable clock skew
  • nonce matches the value you sent (when nonce was included)

When requesting openid, you MUST include a cryptographically random nonce in the initial /oauth/v2/authorize request. This value is echoed in the id_token nonce claim and MUST be validated.

Example /authorize request with nonce:

https://auth.uber.com/oauth/v2/authorize?client_id=<your_client_id>&response_type=code&redirect_uri=<your_client_redirect_uri>&scope=openid%20<other_scopes>&state=<your_state>&nonce=<random_nonce>

Store the nonce on the client and validate the id_token nonce claim matches. See Appendix: Nonce Parameter.

Example /token response with id_token when requesting openid:

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": 2592000,
  "refresh_token": "<refresh_token>",
  "scope": "openid profile",
  "id_token": "<jwt>"
}

Example id_token payload:

{
  "sub": "8OlTlUG1TyeAQf1JiBZZdkKxuSSOUwu2IkO0Hf9d2HV52Pm25A0NvsbmbnZr85tLVi-s8CckpBK8Eq0Nke4X-no3AcSHfeVh6J5O6LiQt5LsBZDSi4qyVUdSLeYDnTtirw==",
  "given_name": "Uber",
  "family_name": "Developer",
  "email": "uberdevelopers@gmail.com",
  "email_verified": true,
  "phone_number": "+12345678910",
  "phone_number_verified": true,
}

For guidance on signature validation, nonce validation, and other security checks, refer to: OpenID Connect Certificates and Verification and OIDC discovery at https://auth.uber.com/.well-known/openid-configuration.

¶ PKCE (Proof Key for Code Exchange)

PKCE strengthens the authorization code flow against code interception. It is strongly recommended for public clients (mobile, desktop, SPAs).

¶ Step 1 - OAuth /authorize with PKCE

Add the following query parameters to your existing GET https://auth.uber.com/oauth/v2/authorize request:

Query Params	Description
code_challenge	Base64url-encoded SHA-256 hash of the code_verifier
code_challenge_method	Must be set to S256

Example Request from browser:

https://auth.uber.com/oauth/v2/authorize?client_id=<your_client_id>&response_type=code&redirect_uri=<your_client_redirect_uri>&scope=<space-delimited-scope>&state=<your_state>&code_challenge=<base64url_sha256_of_code_verifier>&code_challenge_method=S256

Generating values:

• code_verifier: A high-entropy, random string (43–128 chars). Keep it secret on the client and persist it until Step 2.
• code_challenge: BASE64URL( SHA256( code_verifier ) ).

¶ Step 2 - OAuth /token with PKCE

Post to the same token endpoint and include the code_verifier used to create the challenge:

Request Details:

• HTTP Method: POST
• Domain: auth.uber.com
• Path: /oauth/v2/token
• Content-Type: application/x-www-form-urlencoded (Form Body)

Form Body	Description
client_id	Your application’s client ID
redirect_uri	The redirect URI registered for your application
grant_type	Must be set to authorization_code
code	Authorization code returned in Step 1
code_verifier	The original code_verifier used to create the challenge

Example Request:

curl -X POST 'https://auth.uber.com/oauth/v2/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=<client_id>' \
  --data-urlencode 'redirect_uri=<partner_redirect_uri>' \
  --data-urlencode 'grant_type=authorization_code' \
  --data-urlencode 'code=<AUTHORIZATION_CODE_FROM_STEP_1>' \
  --data-urlencode 'code_verifier=<CODE_VERIFIER_USED_TO_CREATE_CHALLENGE>'

Note: If you include PKCE parameters in Step 1, the token request must include the matching code_verifier.

¶ Revoke Token

For token revocation, see OAuth Token Revocation.

¶ Appendix

¶ State Parameter in OAuth Requests

¶ Overview

The state parameter is a crucial part of the OAuth authorization request. It is used to maintain state between the client’s request and the server’s response. This parameter serves two primary purposes:

1. CSRF Protection: The state parameter helps prevent Cross-Site Request Forgery (CSRF) attacks. By including a unique and unpredictable value in the request, the client can verify that the response received from the authorization server corresponds to the request it originally made.
2. Client State Preservation: The state parameter allows clients to pass back any application-specific data necessary to restore the state. This can include information about the user’s session, the current view, or other context needed to continue the user’s interaction seamlessly after the OAuth flow is complete.

¶ How to Use the state Parameter

1. Generate a Unique Value: Before initiating the OAuth authorization request, generate a unique, random string to use as the state parameter. This value should be unpredictable to ensure security.
2. Include the state Parameter in the Request, i.e.
   https://auth.uber.com/oauth/v2/authorize?{params}
3. Store the state Parameter: Store the state value on the client side, such as in a session or a secure cookie. This storage will be used to validate the response from the authorization server.
4. Validate the state Parameter in the Response: When the authorization server redirects back to your application, it will include the state parameter in the response. Verify that this value matches the one you generated and stored. If the values do not match, the response may be part of a CSRF attack and should be rejected.

¶ References for state

1. https://datatracker.ietf.org/doc/html/rfc6749#section-10.12
2. https://auth0.com/docs/secure/attack-protection/state-parameters#set-and-compare-state-parameter-values

¶ Nonce Parameter in OpenID Connect Requests

¶ Overview

The nonce parameter is an OpenID Connect requirement used to associate a client session with an id_token and to mitigate replay attacks. When requesting the openid scope, clients should generate a unique, unpredictable nonce and include it in the /authorize request. The authorization server echoes this value in the id_token nonce claim. To ensure replay protection, the nonce is single-use and MUST NOT be reused.

¶ How to Use the nonce Parameter

1. Generate a high-entropy, random string to use as the nonce (e.g., 128 bits, Base64URL-encoded). Do not reuse nonces; bind them to the user session and apply a short TTL.
2. Include the nonce parameter in the /oauth/v2/authorize request, i.e.
   https://auth.uber.com/oauth/v2/authorize?{params}&nonce=<random_nonce>
3. Store the nonce value on the client (for example, in the user’s session) until tokens are received.
4. Validate that the id_token contains a nonce claim matching the stored value. If the values do not match, reject the response.

¶ References for nonce

1. OpenID Connect Core — Authentication Request
2. OpenID Connect Core — Using nonce