What breaks when OEMs swap OAuth for client assertions — and how a solo builder should adapt

# What breaks when OEMs swap OAuth for client assertions — and how a solo builder should adapt

When an OEM changes its OAuth token endpoint to require JWT-based client authentication, what breaks is simple: unofficial clients that used to “just” submit a username/password-derived grant or a straightforward OAuth exchange can no longer obtain or refresh tokens—because they cannot produce the required signed proof-of-client-identity. Official apps keep working because they already have whatever client authentication material and logic the authorization server now demands, so your integration fails specifically at background reauth (refresh, restart recovery, scheduled polling), surfacing as sudden “login failed” errors despite correct user credentials.

The mechanism: why client assertions change the rules

Volkswagen’s reported move aligns with RFC 7523, which defines a “JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants.” In practical terms, a client assertion is a JWT created by the client and signed in a way that proves the client is an allowed application.

That is a different security property than:

• “resource owner” credentials (a user’s username/password), or
• a simple client secret embedded in a third-party integration.

If the authorization server is configured to reject token requests that lack a valid signed client assertion, then even correct user credentials won’t help: the server is no longer only authenticating the user, it is authenticating the app that is asking for tokens. A reverse-engineered integration that doesn’t possess the signing capability (or isn’t registered to create acceptable assertions) will be denied at the token endpoint.

Builder consequence: your integration’s failure mode shifts from “credentials wrong” to “client is not allowed,” which is harder to remediate without an official registration path.

What exactly breaks in the field: token refresh and restart recovery

Most smart-home integrations aren’t judged on whether a user can log in once in a happy-path flow. They’re judged on whether they can quietly keep tokens valid across:

• Home Assistant restarts,
• scheduled data pulls,
• transient network errors,
• multi-week uptime.

That’s why the most visible symptom in the Volkswagen reports is not “first-time setup is impossible,” but that previously stable installs suddenly can’t reauthenticate. Users describe a pattern where things worked, then after a restart or routine operation the integration can’t obtain tokens anymore while the Android app continues to work.

Builder consequence: you can’t treat authentication as a one-time setup step; you have to design for “auth continuity,” and a server-side change can convert a working integration into a fleet-wide outage overnight.

The Volkswagen We Connect case: what the community observed (Home Assistant)

In late May 2026, community issue threads and discussions converged on the same observable behavior:

• The Home Assistant integration reported “Login no more possible, Android App still works” in GitHub issue #967 in robinostlund/homeassistant-volkswagencarnet (published 2026-05-27).
• Hacker News and forum threads corroborated that Home Assistant integrations and HACS modules using prior auth flows stopped reauthenticating, while official mobile apps remained functional.
• The suspected cause repeatedly mentioned by users is that Volkswagen’s auth flow now requires an RFC 7523-style client assertion, which blocks prior reverse-engineered OAuth techniques.

None of this requires assuming malice; it’s enough to note the structural effect: the authorization server is now enforcing a stronger client authentication requirement that unofficial clients can’t satisfy.

Builder consequence: if your integration’s access depends on being indistinguishable from the official app, a single auth hardening step can end the approach.

Why It Matters Now: OEMs are tightening API access

This incident is a clean, recent example of a broader reality for solo builders in connected-device ecosystems: OEMs can change authentication requirements unilaterally, and the blast radius lands on third-party automation first.

The user impact is immediate and concrete: smart-home automations that depend on continuous vehicle telemetry or command/control lose presence detection, dashboards, and scheduled actions the moment tokens stop refreshing. And because official apps still work, users experience it as “my smart-home platform broke,” even though the OEM has only changed its backend expectations.

The policy dimension is also now explicitly part of community discourse. Hacker News commenters referenced the EU Data Act (including Articles 4 and 5, plus complaint mechanisms such as Article 39) as a potential route to compel access to user-generated vehicle data. But the same threads underscore the practical issue for builders: even if regulatory rights exist, enforcement is slow and uncertain, so you still need short-term operational mitigations.

How to detect the shift: instrument the token endpoint

A solo builder can’t prevent an OEM from hardening auth, but you can detect it quickly and make failures legible.

Concrete steps drawn from how these breaks present:

1. Log token exchange failures with server error codes

Watch for OAuth-style errors such as invalid_client or invalid_grant, and for messaging that hints at missing client authentication (some servers will explicitly reference the client assertion requirement). The point is not the exact string—it’s to distinguish “user credential bad” from “client authentication rejected.”

1. Compare your request shape to a known-good flow (carefully)

The community’s core clue was: “Android app still works.” If you have a legally permissible way to compare request fields at a high level, the goal is to identify what your client cannot produce (e.g., a signed JWT assertion) rather than chasing superficial headers.

1. Add a health signal for reauth failure

Don’t let entities silently stop updating. Surface a clear “authentication expired / cannot refresh” state and notify users promptly. If you persist auth state locally, treat it as durable state (storage corruption can look like auth failure); solo builders often use lightweight durable patterns for this (see: SQLite + Litestream: the minimal durable backbone solo AI builders actually need).

Builder consequence: you reduce time-to-diagnosis and avoid the “it just stopped working” support spiral when the real issue is server-side policy.

Adaptation strategies: what a solo builder can do without shipping secrets (delegation)

Once an OEM requires client assertions, you have three broad paths—each with constraints:

1. Prefer official, documented paths where they exist

If Volkswagen provides a supported API, partner program, or a way to register your own OAuth client (so your app can legitimately create accepted assertions), that is the stable path. The key is: you need a sanctioned way to be a client.

1. Use user-consent flows that don’t embed OEM app credentials

A pragmatic pattern is an OAuth redirect-based flow where the user authenticates in a browser context and grants consent, rather than your integration impersonating an app. Your integration should avoid bundling any “official app” secrets.

1. Architect for graceful degradation

Build UI and automation semantics that can tolerate auth outages: clear error states, disabled actions, and recovery guidance. Treat reauth as a first-class operational workflow, not an exception.

1. Document boundaries explicitly

Make it clear what you will not do (e.g., app key extraction), and what users can do (use the official app; participate in community advocacy; explore regulatory complaint channels where applicable).

Builder consequence: you shift from “imitate the OEM app” to “operate as a user-consented client,” which is the only strategy that survives credential rotation and backend hardening.

When reverse engineering is tempting: the fragility checklist

Community discussions inevitably raise “extract what the app has.” The Volkswagen case also shows why that’s a trap for maintainers:

• Technical fragility: any embedded material can be rotated, flows can change, and hardening can escalate.
• Operational exposure: once a community project shares sensitive material, the OEM has strong incentives to invalidate it quickly, harming all users.
• Legal/policy risk: extracting and using app credentials may violate terms or law; even discussing it as a recommended fix can put maintainers at risk.

Builder consequence: even if it works briefly, it creates an unstable dependency you can’t support responsibly.

What to Watch

• Whether Volkswagen publishes any supported third-party or user-consentable integration path for We Connect / We Connect ID.
• Home Assistant and HACS repository activity indicating shifts away from reverse-engineered flows toward redirect-based OAuth or other delegated patterns.
• Continued evidence of server-side tightening (credential rotation, new client checks) that shortens the lifespan of unofficial approaches.
• Regulatory motion referenced by users (EU Data Act complaint channels, national authority actions) that could eventually pressure OEMs to provide machine-readable, user-authorized access.

Sources:

https://github.com/robinostlund/homeassistant-volkswagencarnet/issues/967

https://news.ycombinator.com/item?id=48319509

https://community.home-assistant.io/t/ha-integration-for-volkswagen-cars/667118

https://www.speakev.com/threads/home-assistant-and-the-vw-api.187786/

https://www.vwidtalk.com/threads/watching-over-the-car-via-home-assistant.2833/

https://www.rfc-editor.org/info/rfc7523/