Smart API Security for Your Smart Car
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
or
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.
