Step1 fails: You don't have permission to access "http://auth.tesla.com/oauth2/v3/authorize?" on this server. #328

DentonGentry · 2021-02-26T01:08:54Z

DentonGentry
Feb 26, 2021

A golang implementation I've been using for a while and modified in January for the Step 1-4 process stopped working again today. I cannot even get through step 1, fetching https://auth.tesla.com/oauth2/v3/authorize results in:

<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>

You don't have permission to access "http&#58;&#47;&#47;auth&#46;tesla&#46;com&#47;oauth2&#47;v3&#47;authorize&#63;" on this server.<P>
Reference&#32;&#35;18&#46;9dc70617&#46;1614300909&#46;1116f2bf
</BODY>
</HTML>

I've updated it to match what the "Working PHP to Generate Refresh Token (Steps 1-4)" does as closely as I can see, switching from sha256 to sha512 and sending a 12 byte state instead of 20 byte. I'm not setting a User-agent. It still tells me I'm not authorized to even fetch the HTML of the authorization page.

The only occurrences of "You don't have permission to access" in this discussion forum are from two other people who got the message even using the PHP code.

Is this something which the community figured out early on so it just doesn't appear in threads here?

DentonGentry · 2021-02-26T01:15:46Z

DentonGentry
Feb 26, 2021
Author

Even fetching from the URI noted in #260 (comment) fails for me:

$ curl "https://auth.tesla.com/oauth2/v3/authorize?client_id=ownerapi&code_challenge=NWQxNjFkMmQzY2Q2OWE5MWQ5MDc5YWU4YWIxYTdiYmVkZjU5ZTczMzI2NDY4Njc2NjYzZTJhMzU1OTBlMDU5OA==&code_challenge_method=S256&redirect_uri=https://auth.tesla.com/void/callback&response_type=code&scope=openid%20email%20offline_access&state=762iuznqj8lyqymdkfj8"
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>

You don't have permission to access "http&#58;&#47;&#47;auth&#46;tesla&#46;com&#47;oauth2&#47;v3&#47;authorize&#63;" on this server.<P>
Reference&#32;&#35;18&#46;97c33d17&#46;1614302076&#46;f6fb7ba
</BODY>
</HTML>

1 reply

stx Feb 26, 2021

Tesla deployed a new WAF configuration at 2pm PST today that has broken many implementations of the new auth system.

pdg364 · 2021-02-26T08:55:13Z

pdg364
Feb 26, 2021

I have the same problem:

Step 1 brings back this as a header:

HTTP/1.1 403 Forbidden

6 replies

HarmOtten Mar 5, 2021

Now working fine again

What did you change to make it work again?

DentonGentry Mar 5, 2021
Author

For me the problem was indeed a CloudFlare WAF update Tesla deployed a few hours before this issue was opened, and apparently corrected late that night. By the next day, without any code changes on my side, it started working again.

HarmOtten Mar 5, 2021

Ok, thanks.
I had everything working beginning of February. Now I needed to login again, and at Step1 I get a "Error: ESOCKETTIMEDOUT". Really frustrating. Maybe because I am temporarily blocked now, but I'm not sure. How long does it take before the block is removed?

Update: I figured it out. I was not blocked, but I had to add 'Accept': "*/*", 'accept-encoding': "deflate" to the requests.

uhthomas Mar 10, 2021

For me the problem was indeed a CloudFlare WAF update Tesla deployed a few hours before this issue was opened, and apparently corrected late that night. By the next day, without any code changes on my side, it started working again.

*Akami, not Cloudflare

Rockster160 Jun 10, 2023

Update: I figured it out. I was not blocked, but I had to add 'Accept': "/", 'accept-encoding': "deflate" to the requests.

Thank you! This is what I needed as well to get the refresh working again.

SG57 · 2021-03-05T00:49:26Z

SG57
Mar 5, 2021

I can reliably cause this error, although trying again a bunch eventually lets me thru after some X amount of time which is a big difference when compared to the official Tesla app. After much testing and sniffing the official app's network traffic, the official app always gets through immediately on their first attempt. Mimicking the network calls from my app verbatim does not yield the same result for me. I mimicked everything so it looks the exact same (headers, order, params, etc.) the only difference is the contents of the code_challenge and state.

I've dug thru the official app source to decipher what the contents of their state is. If you trace your way backwards thru the transpiled garbage you can see it's base64URLEncode(c.sent.bytes) , question is what is c.sent.bytes.

Here is the value of state as sniffed from the app: state=ps_BTXZII3iuIX52-q-CTcjVbUQJd3U2o72jnfGO-kk%0A perhaps someone can make sense of it. Maybe decode it from base-64 into bytes and find something meaningful.

Alternatively, code_challenge could be the one to look at. It's also base64URLEncode, trace it back from there you see it involves hexToBase64 - perhaps that's important. There's 2x random 32-byte arrays generated it appears as well, those don't appear useful.

The official code is:

key: "initializeLoginForm",
                value: function() {
                    var t = this;
                    this._loadStartTime = Date.now(), this._webViewLoaded = !1, (function() {
                        var n, o, s, u;
                        l.default.async(function(c) {
                            for (;;) switch (c.prev = c.next) {
                                case 0:
                                    return c.t0 = k.base64URLEncode, c.next = 3, l.default.awrap(G.default.randomBytes(32));
                                case 3:
                                    return c.t1 = c.sent.bytes, n = (0, c.t0)(c.t1), c.t2 = k.base64ToByteArray, c.next = 8, l.default.awrap(G.default.randomBytes(32));
                                case 8:
                                    return c.t3 = c.sent.bytes, o = (0, c.t2)(c.t3), s = (0, k.base64URLEncode)((0, v.encode)(o.join(""))), c.t4 = k.base64URLEncode, c.t5 = k.hexToBase64, c.next = 15, l.default.awrap((0, b.sha256)(s));
                                case 15:
                                    c.t6 = c.sent, c.t7 = (0, c.t5)(c.t6), u = (0, c.t4)(c.t7), N.default.log("[LOGIN]", "stateString", n, "verifier:", s, "challenge:", u), u && n && t._setViewState({
                                        url: A.default.SSO_SERVER_AUTHORIZE + '?' + (0, E.stringify)({
                                            response_type: "code",
                                            scope: (0, I.ssoScope)(),
                                            client_id: A.default.getSingleSignOnClientID(),
                                            audience: "",
                                            state: n,
                                            redirect_uri: A.default.SSO_SERVER_CALLBACK,
                                            code_challenge_method: "S256",
                                            locale: (0, C.translate)('sso_language_code'),
                                            code_challenge: u,
                                            prompt: "login"
                                        })
                                    }), t._setViewState({
                                        verifierState: s,
                                        authState: n
                                    }), N.default.logEng("[LOGIN] challenge", u, "state:", n);
                                case 22:
                                case "end":
                                    return c.stop()
                            }
                        }, null, this)
                    }

0 replies

DentonGentry · 2021-03-10T17:11:55Z

DentonGentry
Mar 10, 2021
Author

For me at least, this started happening again yesterday and still going on this morning.

6 replies

pgalbavy Mar 10, 2021

I am going to start randomising the user-agent "version" header (the part after the first "/" and see if this explains things

themonomers Mar 25, 2021

I fired up my script to get a new token since it's been almost 45 days since I ran it using this new method. I got the 403 and despite my best efforts, can't get past Step 1.

Not sure why I would get blocked since I haven't ran this script in over a month. Maybe because it's run from Google servers and others are doing the same so it appears like an attack from the same IP?

themonomers Mar 25, 2021

I'm more confident it's some sort of IP block because I took the same URL my script generated in step 1 and pasted into my browser and was able to get the login page. When I use the script I still get the 403, even when I set the user-agent to the same value as my browser.

HarmOtten Mar 25, 2021

Let me know if this helped: #328 (reply in thread)

themonomers Mar 25, 2021

Unfortunately same 403.

Update: It must have something to do with the IP address that Tesla WAF doesn't like. I re-wrote my script in python and ran it from my own machine and it works every time. No user-agent submitted in the header during get or post requests.

Versus running it from Google Apps Script which is hosted by Google - it fails Step 1 every single time. Oh well, at least there are other ways to get the token. The rest of my Google Apps Scripts work fine once I have the token.

alandtse · 2021-04-24T20:53:10Z

alandtse
Apr 24, 2021

As another data point, we started seeing this in Python with an aiohttp implementation in the last week or so. The 403 is dependent on client machine. We opened up an issue with aiohttp since it doesn't appear to affect other mechanisms on the impacted machine (python requests, curl, browser).

1 reply

alandtse Apr 30, 2021

For what it's worth, it looks like Tesla's Akamai Global Hosting server may be the cause of the 403s on the initial get. I ended up switching from aiohttp to httpx. Please reference the issue where there was some discussion on additional steps to try.

mloyd · 2021-05-03T18:43:08Z

mloyd
May 3, 2021

Capping TLS to v1.2 worked for me in python. Same request with v1.3 resulted in 403.

3 replies

mloyd May 4, 2021

P.S. Am I the only one who got Rick Rolled by this? 🤣

 ...
 type="application/javascript"></script>
  <script src="/static/js/tds-text-inputs--password.js" type="application/javascript"></script>

  <!-- @todo rolling index crypto keys: http://bitly.com/2WXBRNp -->
</body>
</html>
'

alandtse May 4, 2021

P.S. Am I the only one who got Rick Rolled by this? 🤣

 ...
 type="application/javascript"></script>
  <script src="/static/js/tds-text-inputs--password.js" type="application/javascript"></script>

  <!-- @todo rolling index crypto keys: http://bitly.com/2WXBRNp -->
</body>
</html>
'

Yah I clicked that too. At least Tesla devs are having fun.

davidhodge Jun 8, 2021

I'm using python and had the issue recur today. Did you also?

Kemmey · 2021-05-09T08:29:23Z

Kemmey
May 9, 2021

Seems like this morning, this issue started affecting clients a bit wider - all my 3rd party Tesla apps now have this issue, and I'm unable to login to any of them.

I've tried changing the user agent string to no avail.

I've not been able to figure out how to force iOS / WKWebView to TLS1.2 as suggested above

2 replies

Kemmey May 9, 2021

Ok - official Tesla app now shows same error. Guess someone is working overtime this weekend

Kemmey May 9, 2021

Aaaand we're back in business - guess person responsible woke up in California :-D

davidhodge · 2021-05-09T18:33:47Z

davidhodge
May 9, 2021

Via my Nikola data, it looks like auth is working again, but Tesla is still experiencing super elevated regular API error rates.

1 reply

vercorsio Jun 6, 2021

on PHP side, the line to had to avoid 403 issue is:
curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_MAX_TLSv1_2); //Force requests to use max TLS 1.2

davidhodge · 2021-06-08T23:32:57Z

davidhodge
Jun 8, 2021

Timeline:

Issue was resolved.
Issue recurred again, but was fixed with a SETOPT (to SSLVERSION_MAX_TLSv1_2)
Now today broken despite a SETOPT

Anyone else find any workarounds?

1 reply

Kemmey Jun 9, 2021

Hey David,

Are you seeing this serverside or client side?

I'm unable to replicate client side in WKWebView - seems to be working.

regislutter · 2021-09-11T09:54:08Z

regislutter
Sep 11, 2021

Any update ? Still can't access/use the Tesla API.

0 replies

leezjs · 2021-11-27T12:49:27Z

leezjs
Nov 27, 2021

I came across the same problem at first.
I simulate the whole process in a browser, and find out that the access URL was switched to tesla's local domain in China: auth.tesla.cn

I just changed the domain from "auth.tesla.com" to "auth.tesla.cn" and did some debug, and everything worked.

0 replies

Urkman · 2023-05-23T20:12:51Z

Urkman
May 23, 2023

I'm currently facing this error since yesterday...
But only on my Linux Server. The same code is running fine on my Mac...

Anyone else facing this problem?

1 reply

shakhbiev Jun 23, 2023

I also encountered the same problem today, although before that it worked well. I can't make a request from any of my servers, it says: "Access Denied"

tsmortenson · 2023-07-10T10:30:24Z

tsmortenson
Jul 10, 2023

Newly trying this out from Japan and get the Access Denied error. Tried a couple different client IPs, but the same result.

You don't have permission to access "http://auth.tesla.com/oauth2/v3/authorize" on this server.<P>
Reference #18.4e6a3417.1688983666.1c63aedb

From everything I can find, it looks like an Akamai problem.
Their page to check my IP reputation score says: The IP Address xxx.xxx.xxx.xxx did not receive a bad risk score.
https://www.akamai.com/us/en/clientrep-lookup/

I tried connection to both "auth.tesla.com" and "auth.tesla.cn". But they both result in the same Access Denied error.

0 replies

Step1 fails: You don't have permission to access "http://auth.tesla.com/oauth2/v3/authorize?" on this server. #328

Replies: 13 comments · 22 replies

DentonGentry Feb 26, 2021 Author

HTTP/1.1 403 Forbidden

DentonGentry Mar 5, 2021 Author

DentonGentry Mar 10, 2021 Author

Replies: 13 comments 22 replies

DentonGentry
Feb 26, 2021
Author

DentonGentry Mar 5, 2021
Author

DentonGentry
Mar 10, 2021
Author