Open Source Tokens
Developers working on open-source projects or projects that require publicly available credentials, can onboard their Tesla application as an "Open Source App". This will enable the PKCE flow using a client ID without client secret. Open Source Apps are restricted to the discovery tier and cannot generate or access APIs that require client credentials tokens (Partner Authentication Token).
Similar to third-party tokens, open-source tokens use the authorization_code
grant flow to generate a token on behalf of a customer. This allows API calls using the scopes granted by the customer.
Step 1: User Authorization
For the open-source token authorize request, a PKCE-enhanced Authorization Code flow is required. To use PKCE-enhanced Authorization Code flow, an app generates a code verifier and derives a code challenge from it. The challenge is sent with the authorization code request, and the verifier is sent with the access token request. The authorization server verifies the requests by recalculating the challenge and matching it with the original. More instructions on generating code_challenge
and code_verifier
can be found here: https://tools.ietf.org/html/rfc7636#page-8.
To initiate the authorization code flow direct the customer to an /authorize
request.
https://auth.tesla.com/oauth2/v3/authorize
Parameters
Name | Required | Example | Description |
---|---|---|---|
response_type | Yes | code | A string, always use the value "code". |
client_id | Yes | abc-123 | Partner application client ID. |
redirect_uri | Yes | https://example.com/auth/callback | Partner application callback url, spec: rfc6749. |
scope | Yes | openid offline_access user_data vehicle_device_data vehicle_cmds vehicle_charging_cmds | Space delimited list of scopes, include openid and offline_access to obtain a refresh token. |
state | Yes | db4af3f87... | Random value used for validation. |
code_challenge | Yes | bFoI-q1X6yH2-kBGEZ3gkv3JNd527d7ZWIw-KmIFm6I | Randomly generated encrypted key from "code_verifier" that will be used for requesting a token. |
nonce | No | 7baf90cda... | Random value used for replay prevention. |
Example Request
https://auth.tesla.com/oauth2/v3/authorize?&client_id=$CLIENT_ID&locale=en-US&prompt=login&redirect_uri=$REDIRECT_URI&response_type=code&scope=openid%20vehicle_device_data%20offline_access&state=$STATE&code_challenge=$CODE_CHALLENGE
Step 2: Callback
After the user authorizes their account with Tesla, they will be redirected to the specified redirect_uri
.
Extract the code
URL parameter from this callback.
Step 3: Code Exchange
Execute a code exchange call to generate a token. The access_token
can be used for subsequent requests to Fleet API on behalf of the user.
If using the offline_access
scope, save the refresh_token
to generate tokens in the future. The refresh token is single use only and expires after 3 months.
An invalid_auth_code
response likely means the code
is expired.
POST https://auth.tesla.com/oauth2/v3/token
Parameters
Name | Required | Example | Description |
---|---|---|---|
grant_type | Yes | authorization_code | Grant type must be authorization_code. |
client_id | Yes | abc-123 | Partner application client ID. |
code | Yes | a90869e9d... | Code from authorize request callback. |
audience | Yes | https://fleet-api.prd.na.vn.cloud.tesla.com | Audience for the generated token. Must be a Fleet API base URL. |
code_verifier | Yes | S94sfZq9709HXnQlIYh9TOavL0GNd4z-h8FSwA9SLGY | Randomly generated key (unchallenged/unencrypted) for the "code_challenge" that was sent to the authorize endpoint. |
redirect_uri | Yes | https://example.com/auth/callback | Partner application callback url, spec: rfc6749. |
scope | No | openid offline_access user_data vehicle_device_data vehicle_cmds vehicle_charging_cmds | Space-delimited list of scopes. |
Example Request
# Authorization code token request
CODE=<extract from callback>
curl --request POST \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode "client_id=$CLIENT_ID" \
--data-urlencode "code=$CODE" \
--data-urlencode "audience=$AUDIENCE" \
--data-urlencode "code_verifier=$CODE_VERIFIER" \
--data-urlencode "redirect_uri=$CALLBACK" \
'https://auth.tesla.com/oauth2/v3/token'
# Extract access_token and refresh_token from this response
Refresh Tokens
Use the refresh_token to generate new tokens and obtain refresh tokens. There are two common failure modes for using a refresh_token that will return a 401 - login_required response:
- The refresh token has already been used; only the newest refresh token is valid.
- The user has reset their password.
Parameters
Name | Required | Example | Description |
---|---|---|---|
grant_type | Yes | refresh_token | Grant type must be refresh_token. |
client_id | Yes | abc-123 | Partner application client ID. |
refresh_token | Yes | NA_a90869e9d... | Refresh token from the code exchange response. |
Example Request
# Refresh token request
REFRESH_TOKEN=<extract from authorization code token request>
curl --request POST \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode "client_id=$CLIENT_ID" \
--data-urlencode "refresh_token=$REFRESH_TOKEN" \
'https://auth.tesla.com/oauth2/v3/token'
Scope Changes
Once a user has granted scopes to an application, they can modify scopes or revoke access using the consent management page:
https://auth.tesla.com/user/revoke/consent?revoke_client_id=$CLIENT_ID&back_url=$RETURN_URL
Scope modifications are compatible with existing refresh tokens and will be applied to new access tokens.