Tesla SSO header requirements updated

[SG57]

My app started timing out when POST'ing to the /oauth2/v3/token endpoint when signing in.

After some testing found the User-Agent header needed updating to the following value:

Mozilla/5.0 (Linux; Android 5.1; XT1031 Build/LPB23.13-56; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/89.0.4389.72 Mobile Safari/537.36

The only difference was in the final chrome version, it went from 88.0.xxx to 89.0.xxx.

The other required headers are already what has been discussed on here before, but for sanity they are:

Accept: application/json
Accept-Encoding: deflate, br

[theftprevention]

I'm curious, because I've seen a lot of conflicting requirements / success stories around the User-Agent. The docs still claim that it's required, but that it shouldn't look like a browser:

The SSO service has protections in place that will require executing JavaScript if a browser-like user agent is detected.

Could that be what happened to your app? Chrome v90 released on April 14, and your app stopped working around 10 days later until you bumped the User-Agent version from 88 to 89. Maybe the SSO service is keeping pace with browser updates, and intentionally stays one or two major versions behind?

I'm working on a Node.js project that's been hitting API endpoints successfully for the past week or two, and so far I've been sending a non-browser User-Agent (theftprevention/tesla-api 0.1.0) with all requests, authenticated or otherwise. For example, here are the HTTP/2 headers in my outgoing request for step 3:

:authority: auth.tesla.com:443
:method: POST
:path: /oauth2/v3/token
:scheme: https
accept: application/json
content-type: application/json
content-length: 287
cookie: (Cookies from step 1)
user-agent: theftprevention/tesla-api 0.1.0

I hope that this helps someone, and that I'm not just adding to the confusion (especially since neither of our solutions can explain why some people are only successful after removing the User-Agent entirely)!

[SG57]

I understand, makes sense why you'd want to avoid looking like a web browser. However I am strictly copying what the official Tesla Android app's network traffic looks like verbatim. I use a rooted device with a special Xposed SSL cert pinning bypass module I wrote in order to do this.

They use a React web page inside an Android web view and I can confirm their network traffic headers are what I've posted. I've tried removing the User-Agent, bunch of other combinations that have been posted here the past 6 months and in the end my app would always get stuck with 403 forbidden or timeouts. It would be nice to have a conclusive solution here that doesn't involve updating headers, but for now mimicking the official app has been my only option.

[theftprevention]

That makes sense. I was shooting in the dark with the browser version theory; it sounds like you're several steps ahead of me!

Either way, if my solution continues working reliably, I'll try to publish my code sometime soon in hopes that it will provide another example to work from.

[alandtse]

I spent some time looking at the 403. It look like Tesla is using an Akamai Global Host content server that may have some anti script protections in place and may be triggered by random things. For example, I had code using aiohttp in python that worked for a couple of weeks and then last week broke randomly for people. The same code would break randomly within the same network in docker hosts and docker containers (sometimes the host would work, sometimes the container would work). If it worked or got the 403, it was consistent for that machine.

While we never narrowed it down, there was some speculation that it was due to SSL fingerprinting or some other set of combined heuristics. For example, checking for certain behavior based on the provided User-Agent to detect spoofing.

Check the 403 discussion for links. You can Google Akamai Global Host to see people complaining about it generally.

[vercorsio]

I cannot count how much time I spent on the 403 issue, but I finally ended up with a solution. 🥳
Note: I am using PHP and curl for connections to Tesla servers.

The problem was present for many users who use my Tesla Jeedom Plugin, when others have no issues with connection.

I was able to reproduce the 403 issue with the php code deployed on a VM installed on my laptop (as my tesla plugin deployed on my Rpi has no issue)

Using MFA the connection was stopped at step 3 (https://auth.tesla.com/oauth2/v3/token) with a "Access Denied" and 403 HTTP error code.

I have added this :
curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_MAX_TLSv1_2); //Force requests to use max TLS 1.2

to my Curl options... and step 3 now successfully works (BTW: no cookies sent at this stage)

My 2 cents

Nicolas

[robertkleinschuster]

@vercorsio

thank you so much, i would have never guessed to set the curl TLS version. We have to get @timdorr to post this on his guide.

[vercorsio]

@robertkleinschuster: you're welcome ! I'm quite surprised that my 2y old message can be still helpful. Glad to help. Thanks for your message 😀