Authentication overview

Smartcar's authentication system is built on the OAuth 2.0 authorization framework, which allows applications to obtain limited access to a user's vehicle data without ever handling the user's login credentials. This delegated authorization model is standard for securing access to protected resources across various web services.

The core of Smartcar's authentication process involves two main components: the Smartcar Connect SDK and the Smartcar API. The Connect SDK facilitates the user authorization flow, enabling vehicle owners to grant consent for their vehicle data to be accessed by a third-party application. Once consent is granted, the application receives an authorization code, which is then exchanged for an access token and a refresh token.

Access tokens are short-lived credentials used to make authenticated requests to the Smartcar API. Refresh tokens, on the other hand, are long-lived and are used to obtain new access tokens once the current ones expire, minimizing the need for users to re-authorize frequently. This separation of concerns enhances security by limiting the exposure of sensitive credentials and providing a mechanism for token revocation.

Developers integrate Smartcar authentication by registering their application, configuring redirect URIs, and implementing the OAuth 2.0 flow within their application's backend. Smartcar provides SDKs in various languages to simplify this integration, including JavaScript, Python, and Node.js, among others.

Supported authentication methods

Smartcar primarily supports OAuth 2.0 for authenticating applications and authorizing access to vehicle data. The specific OAuth 2.0 grant types used depend on the application's architecture and the context of the authorization request.

Method When to Use Security Level
OAuth 2.0 Authorization Code Grant Server-side applications, web applications, and mobile applications where the client secret can be securely stored. This is the recommended and most secure flow for most applications. High: Client secret is exchanged server-side, preventing exposure to the user agent.
OAuth 2.0 Implicit Grant Single-page applications (SPAs) or client-side applications where the client secret cannot be securely stored. While supported, the Authorization Code flow with PKCE is generally preferred for SPAs for enhanced security. Medium: Access token is returned directly in the redirect URI, potentially exposing it to browser history or third-party scripts.
Refresh Tokens To obtain new access tokens without requiring the user to re-authenticate, ensuring continuous access to vehicle data. High: Refresh tokens are long-lived and securely stored server-side, used only to acquire new access tokens.

The Connect SDK simplifies the implementation of these flows by providing a user-friendly interface for vehicle owners to log in and grant permissions. Once a user authorizes their vehicle, Smartcar issues an authorization code, which your application then exchanges for an access token and a refresh token. The Smartcar API reference details how to use these tokens for subsequent API calls.

Getting your credentials

To begin integrating with Smartcar, you must first register your application and obtain the necessary credentials. This process involves creating a developer account and setting up an application within the Smartcar Dashboard.

  1. Create a Smartcar Developer Account: Navigate to the Smartcar developer documentation and follow the instructions to sign up for a free developer account. This account provides access to the Smartcar Dashboard.
  2. Register Your Application: Once logged into the Smartcar Dashboard, create a new application. During this process, you will be prompted to provide an application name and at least one Redirect URI.
  3. Identify Your Client ID and Client Secret: After registering your application, Smartcar will provide you with a unique Client ID and Client Secret. The Client ID is a public identifier for your application, while the Client Secret is a confidential key that must be kept secure. These are essential for initiating the OAuth 2.0 flow.
  4. Configure Redirect URIs: The Redirect URI (also known as Callback URL) is where Smartcar redirects the user's browser after they have authorized their vehicle, along with the authorization code. You must register all valid Redirect URIs in your Smartcar Dashboard settings. For security reasons, Smartcar will only redirect to pre-registered URIs.
  5. Set Scopes: Scopes define the specific permissions your application requests from the vehicle owner (e.g., read odometer, lock/unlock doors). You configure these scopes during the authorization request. Requesting only necessary scopes adheres to the principle of least privilege, enhancing security.

It is crucial to store your Client Secret securely and never expose it in client-side code or public repositories. Treat it like a password for your application.

Authenticated request example

Once you have obtained an access token, you can use it to make authenticated requests to the Smartcar API. Access tokens are typically included in the Authorization header of HTTP requests using the Bearer scheme.

Here's an example of how to make an authenticated request using Node.js to retrieve a vehicle's odometer reading, assuming you have already obtained an access_token and the vehicle_id:


const Smartcar = require('smartcar');

const accessToken = 'YOUR_ACCESS_TOKEN'; // Obtained after user authorization
const vehicleId = 'YOUR_VEHICLE_ID'; // Obtained from the Smartcar API after authorization

const smartcar = new Smartcar({
  clientId: 'YOUR_CLIENT_ID',
  clientSecret: 'YOUR_CLIENT_SECRET',
  redirectUri: 'YOUR_REDIRECT_URI',
  scope: ['read_vehicle_info', 'read_odometer'], // Scopes must match what was authorized
});

async function getOdometer() {
  try {
    const vehicle = new smartcar.Vehicle(vehicleId, accessToken);
    const odometer = await vehicle.odometer();
    console.log('Odometer reading:', odometer.data.distance);
    console.log('Unit:', odometer.data.unit);
  } catch (err) {
    console.error('Error fetching odometer:', err);
  }
}

getOdometer();

In this example, the accessToken is passed when initializing the smartcar.Vehicle object, which then handles including the token in the request headers. For direct HTTP requests without an SDK, the header would look like this:


GET /v2.0/vehicles/{vehicle_id}/odometer HTTP/1.1
Host: api.smartcar.com
Authorization: Bearer YOUR_ACCESS_TOKEN

Remember to replace YOUR_ACCESS_TOKEN, YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URI, and YOUR_VEHICLE_ID with your actual values. The specific endpoints and required scopes are detailed in the Smartcar API documentation for odometer data.

Security best practices

Implementing robust security practices is critical when handling sensitive vehicle data. Adhering to these guidelines helps protect both your application and your users.

  • Secure Your Client Secret: The Client Secret must be kept confidential. Never embed it in client-side code (e.g., JavaScript in a web browser or mobile app). Store it securely on your server and access it only from trusted backend services. Compromise of the client secret could allow unauthorized access to your application's Smartcar account.
  • Use HTTPS for All Communications: Ensure all communication between your application, Smartcar, and the user's browser occurs over HTTPS (TLS/SSL). This encrypts data in transit, preventing eavesdropping and tampering. Smartcar enforces HTTPS for all API endpoints and redirect URIs.
  • Validate Redirect URIs: Always register specific and exact Redirect URIs in your Smartcar Dashboard. Avoid using wildcard URIs. This prevents malicious actors from intercepting authorization codes by redirecting to an uncontrolled endpoint. The OAuth 2.0 specification on redirect URI validation emphasizes this security measure.
  • Implement Proper Scope Management: Request only the minimum necessary scopes for your application's functionality. Over-requesting permissions can lead to user distrust and unnecessary data exposure if your application is compromised. Users are more likely to grant access when they understand why specific permissions are needed.
  • Securely Store Access and Refresh Tokens: Access tokens and refresh tokens should be stored securely. For server-side applications, use encrypted databases or secure key-value stores. Avoid storing them in plain text. For mobile applications, use platform-specific secure storage mechanisms (e.g., iOS Keychain, Android Keystore).
  • Handle Token Expiration and Refresh: Implement logic to gracefully handle access token expiration using refresh tokens. When an access token expires, use the refresh token to obtain a new access token without requiring the user to re-authorize. If a refresh token is compromised or expires, guide the user through re-authorization.
  • Error Handling and Logging: Implement robust error handling for authentication failures and log relevant events. This helps in identifying and responding to potential security incidents, such as unauthorized access attempts or token misuse.
  • Regularly Review Security Practices: Periodically review your application's authentication and authorization implementation against current security best practices and Smartcar's updated documentation. Stay informed about new security threats and mitigation strategies.