Authentication Overview
Every authenticated interaction with the JLR Data Hub is secured with OAuth2. Which grant type you use depends on who you are and what you are building. This page explains the grant/persona matrix and the two different token models - one for the REST API, one for MQTT streaming.
Clients authenticate at the token endpoint with a signed JWT client assertion
(private_key_jwt), verified against the public certificate you upload when you
create your credentials. There is no client_secret. See
Client Assertion.
Which grant type do I use?
| Persona | Grant type(s) | Used for |
|---|---|---|
| Vehicle owner / customer | Authorization Code + PKCE (browser) or Device Code (constrained device) | REST API access to your own vehicle. |
| Vehicle owner / customer | Client Credentials | MQTT streaming of your own vehicle data. |
Two token models: REST vs streaming
The platform exposes two independent, parallel solutions, and they secure requests differently. This is the single most important thing to understand about authentication here.
| REST API | MQTT streaming | |
|---|---|---|
| Token obtained via | Authorization Code, Device Code, or Client Credentials | Client Credentials |
| How the token is presented | Authorization: DPoP <access_token> header | As the password on the MQTT connection |
| DPoP proof required? | Yes - a fresh DPoP proof JWT per request | No - DPoP is not used for streaming |
| Transport | HTTPS | MQTT over TLS (mqtts) |
In other words: DPoP applies to the REST API only. When you connect an MQTT client, you authenticate by supplying your access token as the connection password
How it works (REST API)
How it works (MQTT streaming)
What a token can access
The platform does not use developer-requested scopes. Instead, access is bound to the client configuration set at credential-creation time: you select the specific vehicles (VINs) and data categories your client may access.
A token issued to a client can only reach what that client was configured for. There is nothing to request at authentication time - and nothing to widen without changing the client's configuration in the portal.
Security model
| Layer | Mechanism |
|---|---|
| Client authentication | JWT client assertion - private_key_jwt (RFC 7523), verified against your uploaded public certificate |
| API authorization | OAuth2 Bearer token (JWT) |
| REST token binding | DPoP proof (RFC 9449) |
| Key algorithm | PS256 (RSASSA-PSS, SHA-256) |
| Access-token lifetime | Short-lived (see Tokens & Refresh) |
| REST replay protection | Unique jti per DPoP proof |
| Streaming transport | TLS (mqtts) |
Authorization server
All authentication happens on the dedicated Auth Server (the public realm),
not on the API gateway. The REST API base URL (https://data.jlr-vcdp.com) is
only for data endpoints.
The auth server base URL is:
https://auth.jlr-vcdp.com/realms/public
Its standard OpenID Connect endpoints:
| Endpoint | URL |
|---|---|
| Authorization | https://auth.jlr-vcdp.com/realms/public/protocol/openid-connect/auth |
| Token | https://auth.jlr-vcdp.com/realms/public/protocol/openid-connect/token |
| Device authorization | https://auth.jlr-vcdp.com/realms/public/protocol/openid-connect/auth/device |
The full OIDC configuration is published at
https://auth.jlr-vcdp.com/realms/public/.well-known/openid-configuration.
Next steps
- Client Assertion - Sign the JWT that authenticates every token request.
- Authorization Code + PKCE - Browser and delegated flows.
- Device Code - For input-constrained devices (customers).
- Client Credentials - Server-to-server and MQTT.
- DPoP - Proof-of-possession for REST requests.
- Tokens & Refresh - Token types, lifetimes, and refreshing.