Smart API Security for Your Smart Car

Jonas Iggbom
· 4 min readKey Takeaways
Connected car breaches (like the Tesla hack) show how API vulnerabilities can expose sensitive fleet and customer data, not just vehicle functionality.
Token-based architecture should replace static API keys, which are inflexible and slow to rotate if compromised.
JWTs let APIs validate access directly, but placing an API gateway in front adds stronger protection — handling authentication, coarse-grained authorization, and reducing direct token exposure to clients.
The Phantom or Split token approach keeps JWTs out of public clients' hands, lowering the risk of leaking PII.
A developer portal, paired with dynamic client registration, creates clear one-to-one mapping between tokens and the developer/app using them — improving accountability and control.
A centralized OAuth server should handle all token issuance (authentication, authorization, signing) rather than distributing that responsibility.
Tools like a DevOps Dashboard let developers monitor API security and respond to issues without needing full identity-team access — useful for time-critical situations.
On this page
With cars becoming more connected and smarter than ever before, security breaches and vulnerabilities are rising. Exploits such as the recent Tesla hack should be viewed as a severe warning to the automotive industry as a whole. Even if minor, these attacks can easily lead to serious consequences.
For example, imagine a situation in which an API responsible for connecting a fleet of cars to your taxi system is breached. The malicious agent could then access sensitive data, such as the names and addresses of your clients and more. Therefore, API security should be a must for automotive companies and services developing API platforms and car applications.
Below, I will introduce the fundamental principles of API security that connected cars should be aware of. These are more or less universal and applicable to all industries, too, so ensure your company follows them all as a solid foundation.
1. Use a Token-Based Architecture to Protect Your Car APIs
Token-based architecture should be at the center of your API security system. Its superiority over legacy solutions in these scenarios is obvious. Since the legacy approach is focused around deploying static API keys, it is quite inflexible and unscalable. If an API key is lost, stolen, or exposed, it must be rotated and updated in all the clients consuming that API. This could be a time-consuming task leaving the API vulnerable until resolved.
Another problem is that the API key retrieval process is complicated. Regardless of whether a user or a system requests access to the API, the request must be authenticated somehow. Without proper authentication, there is a huge risk of having the data and even vehicle functionality exposed to third parties.
In a token-based architecture, the handling of APIs is much more flexible and allows for different scenarios and different levels of security. However, tokens should be handled properly to reap the benefits of this approach.
2. Adopt Smart Token Validation to Prevent Breaches and Data Loss
When it comes to validating access tokens used to protect APIs, several approaches are possible. Having APIs themselves validate access tokens is one of them. In this case, JSON Web Tokens (JWTs) are recommended as they hold a set of claims that the API itself can consume to determine or authorize what information to return to the caller.
An even better approach is to place an API gateway in front of public and internal APIs to add additional security measures. Some of the reasons in favor of an API gateway are:
It allows handling authentication and authorization of API calls. We recommend implementing the Phantom token or Split token approach for more robust security.
The API gateway can initially verify access tokens and handle coarse-grained authorization using scopes so that APIs are not running the initial token validation and frequent introspection calls.
The use of API gateways reduces unauthorized calls to APIs. If the Phantom or Split token approach is used, public applications don't need to hold a JWT, reducing the risk of leaking PII information. The JWT is obtained by the API gateway and validated before it is sent to the API itself.
3. Empower Your Developers with a Developer Portal
A good developer portal is critical for success when securing and managing APIs. They help developers understand how to use multitudes of APIs, track API usage, and monitor who is accessing an API and when.
With the token-based architecture in place, a specific client ID is mapped to a developer or app. Therefore, it is possible to determine the legitimacy of access based on the token presented. The process is automated with dynamic client registration, which is used to establish an integration between the developer portal and the identity provider (IdP). With this in place, the developer portal can tell the IdP to generate a new client to control the token issuance. This way, a one-to-one mapping between the token distribution and the developer or app is created.
How Can the Curity Identity Server Help?
The Curity Identity Server enables a flexible and scalable set-up that can easily integrate with any API gateway in the market. Also, Curity's subsystems are each designed to serve a unique purpose — and perform it very well. This flexibility and "separation of concerns" enables the Curity Identity Server to address the identity structure of today while being future-proofed for the challenges of tomorrow. These attributes are becoming crucial considering the rapid development of connected car systems.
Tokens are crucial when it comes to protecting APIs and managing access. Issuing tokens requires many complex processes: authenticating the client, authenticating the user, authorizing the client, signing the tokens, and other operations. A centralized OAuth Server, such as the Curity Identity Server, should always issue these tokens to ensure your systems are secure.
To make the process of managing access and tracking API usage, consider using Curity's DevOps Dashboard. It empowers your developers and helps them communicate with APIs or monitor the API security without needing to contact the identity team. It is especially useful when the task is time-critical — this way, operations can view information and warnings and react to alarms without needing full access to the server.
API security must be prioritized throughout the automotive industry wherever it isn't already. The principles outlined above will give you a good foundation. And, by using the many security features available in the Curity Identity Server, you can securely protect your APIs and connected systems from many different attack vectors.
Related resources
Frequently Asked Questions
Do connected cars typically use the same API security standards as other IoT devices?
Largely yes — the core principles (token-based auth, API gateways, proper validation) apply broadly across IoT and connected device ecosystems, though automotive systems often have additional real-time and safety-critical constraints that require extra care in implementation.
How often should API tokens for connected car systems be refreshed or rotated?
This depends on the specific token type and risk profile, but short-lived access tokens combined with a secure refresh mechanism are generally recommended over long-lived static credentials, minimizing the window of exposure if a token is ever compromised.
What happens if a car loses internet connectivity — does token-based authentication still work?
Token validation typically requires connectivity to reach the API and authorization infrastructure, so a car offline would generally be unable to complete new authenticated requests until connectivity is restored, though some systems may cache limited local functionality for essential operations.
Are there industry-specific regulations for API security in the automotive sector?
Yes — regulations and standards like UNECE WP.29 (covering cybersecurity for vehicle type approval) and ISO/SAE 21434 address automotive cybersecurity requirements, which increasingly intersect with API and connected system security practices.