Concerns about Tesla API Token process

[pinball_player]

You are correct. The best way that Tesla should implement security is as follows:

1. Allow anyone wanting to use the Tesla API to be able to register a 'client' in the Tesla identity service.
2. Use method two above so that the username/password is never known by the service that wants to use the Tesla API
3. The Tesla identity service should have an 'allow access to client xxx' checkbox
4. Issue a short lived access token (5 or so minutes), and a refresh token (good for a long period of time)
5. When the service wanting access needs to, it sends its refresh token, along with the key and secret to get a new access/refresh token
6. Allow the user to disable access to a specific client that was previously allowed (You are no longer using client xxx so you should be able to disable access for that client, but not have to disable all other access.

There is an open source identity provider called Keycloak which we use in the company that I work for that does all of this. This is what Tesla should provide.

Microsoft/Facebook/etc. does this with their logins also.

 

[nil0lab]

See the revoke method at
OAuth - Tesla API

 

[HarmOtten]

@nil0lab,
Do you know what parameters you need to pass to this revoke request?

 

[ianatoly]

@HarmOtten, you probably already figured it out, but JIC - I was researching the same topic, and I have found OAUTH token revocation RFC very helpful: RFC 7009 - OAuth 2.0 Token Revocation.

Quick summary: you simply need to send the token you need to revoke as URL-encoded parameter in the body of a POST request:

curl -H "Authorization: Bearer ${TOKEN}" "${ROOT}/oauth/revoke" --data "token=${TOKEN}"

 

[darth_vad3r]

@HarmOtten, you probably already figured it out, but JIC - I was researching the same topic, and I have found OAUTH token revocation RFC very helpful: RFC 7009 - OAuth 2.0 Token Revocation.

Quick summary: you simply need to send the token you need to revoke as URL-encoded parameter in the body of a POST request:

curl -H "Authorization: Bearer ${TOKEN}" "${ROOT}/oauth/revoke" --data "token=${TOKEN}"

LOL, I had previously 'liked' this post ... forgotten about it, was playing around and couldn't figure out why revoke didn't work, finally figured it out, came to find a thread to post results on and ... found this post that already told me what I needed to know and just figured out for myself

*sigh* ... I retraced your steps exactly. Circuitously made my way to same RFC 7009 you linked, realized it had a field for token, tried that and it worked .. the API doc linked in prior post fails to mention the need for a field.

Before this I had gotten refresh_token working and was going to rely on that to revoke the original token, but that still leaves a valid token around.

Revoke kills the original, and also makes its refresh_token invalid (I verified you cannot refresh_token after original token revoked).

Anyways ... I'm still reluctant to give a token to a 3rd party ... but knowing I can create a token now, try out a 3rd party app, and then revoke that single token, without having to reset my password, or revoke my own API tokens ... I might try out some of these apps to compare features.

I'll probably just putz around with my own scripts for now though.

 

[ChrML]

As others have mentioned, Tesla seems to use a pretty standars authentication scheme based on OpenID Connect (which is based on OAuth 2.0). I have a fair amount of experience with this myself after building a single-sign-on service from scratch.

The CLIENT_ID and the CLIENT_SECRET is not used for security or encryption. Even if everyone know it, you can't use it for anything except making your own Tesla token requester application/Tesla signin.

It is actually really hard to keep this a secret, because the client needs to know it in order to be accepted by the server to get new tokens. Even if you encrypt it, someone will be able to find it in the application memory after decryption before contacting the server.

The authentication process itself is fairly standard and the same as Facebook uses. This is a very secure solution that nobody has been able to hack yet. Not going into detail on that, google OAuth 2.0 to get more info.

What IS a security issue is that every Tesla 3rd party app allows the user to authenticate using the Tesla username and password. The user has no guarantee that the 3rd party software doesn't store this somewhere and that the creator of the app cannot access these passwords. As a 3rd party app creator all you need to do is store every username/passwore as clear text in a SQL database and you can steal thousands of cars tomorrow. All it takes is post a link to it here telling everyone how awesome your 3rd party app is.

If Tesla 3rd party apps were supposed to be secure like it should be, Tesla should do the following:

- Change the client id and client secret, give a little bit more effort to encrypt it and at the same time tell people not to log in anywhere else than Tesla App or Tesla.com (people will find the new client secret anyway, so this is just to ease the transition to a more secure system by making existing systems cease to function until they find the new secret)

- Make an app overview in the Tesla App and at Tesla.com where the user can see and revoke which Tesla 3rd party apps have access to account.

- When a 3rd party app wants access, it will redirect to Tesla's single-sign-on so that only Tesla will get the username and password. The the user will have to accept which permissions the app needs. For example: No need for TeslaFi to be able to unlock your car or drive it keyless.


Summary: This only lets Tesla official servers see your username/password. This also prevents owners of 3rd party apps from stealing your cars.

 

[darth_vad3r]

Or you can just use choose to only use apps that support the use of tokens instead of username/password, and generate the tokens yourself directly with Tesla.

They are individually revocable (I just posted about this above) so you can shut down 3rd party apps.

The only thing Tesla's missing here is an easy way for you to get your own tokens. If you can write a script and call curl, you can do it fairly easily on your own though.

 

[ChrML]

Or you can just use choose to only use apps that support the use of tokens instead of username/password, and generate the tokens yourself directly with Tesla.

They are individually revocable (I just posted about this above) so you can shut down 3rd party apps.

The only thing Tesla's missing here is an easy way for you to get your own tokens. If you can write a script and call curl, you can do it fairly easily on your own though.

Yepp that's the best way. They should make it easier to generate tokens though and control their permissions. And make it so app creators can create their own client_id's so users can seamlessly single-sign-on securely without needing to generate the tokens themselves.

It's not much work. It took me about 1 week to get all this working based on Identity Server 4 library. And I'm just 1 developer, Tesla has hundreds.

 

[RTPEV]

Or you can just use choose to only use apps that support the use of tokens instead of username/password, and generate the tokens yourself directly with Tesla.

They are individually revocable (I just posted about this above) so you can shut down 3rd party apps.

Are you sure about this? Granted, it's been awhile since I've delved into this, but I recall that Tesla was not providing a way for separate apps to register their own CLIENT_ID/CLIENT_SECRET. Instead, all these 3rd party apps are simply using the standard Tesla app's CLIENT_ID/CLIENT_SECRET (which despite their name, have been made public). So you can't actually generate different tokens for TeslaFi and other 3rd party apps...they all end up using the same token, which all have the same permissions, and if you end up revoking one you essentially revoke all.

Has this changed? Has Tesla provided a way for 3rd parties to register their own apps?

 

[f205v]

No it has not changed.
One token at a time, valid for all apps.

 

[appleguru]

To add some detail, if you want to see it from the source yourself, download the latest Tesla app apk, extract it, and open the assets/shared/env.json file

The latest android app seems to be using:

"OWNERAPI_CLIENT_ID": "81527cff06843c8634fdc09e8ac0abefb46ac849f38fe1e431c2ef2106796384",
"OWNERAPI_CLIENT_SECRET": "c7257eb71a564034f9419ee651c7d0e5f7aa6bfbd18bafb5c5c033b093bb2fa3",

 

[darth_vad3r]

Yepp that's the best way. They should make it easier to generate tokens though and control their permissions. And make it so app creators can create their own client_id's so users can seamlessly single-sign-on securely without needing to generate the tokens themselves.

It's not much work. It took me about 1 week to get all this working based on Identity Server 4 library. And I'm just 1 developer, Tesla has hundreds.

I think they are probably fine walking the line between allowing 3rd party apps by not shutting them down, and not having to support it officially and any support overhead that would entail.

Maybe in the future they’ll do it “right”. I’d prefer the status quo over a change in the other direction of shutting out the API access though

 

[darth_vad3r]

Are you sure about this? Granted, it's been awhile since I've delved into this, but I recall that Tesla was not providing a way for separate apps to register their own CLIENT_ID/CLIENT_SECRET. Instead, all these 3rd party apps are simply using the standard Tesla app's CLIENT_ID/CLIENT_SECRET (which despite their name, have been made public). So you can't actually generate different tokens for TeslaFi and other 3rd party apps...they all end up using the same token, which all have the same permissions, and if you end up revoking one you essentially revoke all.

Has this changed? Has Tesla provided a way for 3rd parties to register their own apps?

No it has not changed.
One token at a time, valid for all apps.

I said tokens folks. You are taking about the client id/secret. A token is something you get in exchange for your login credentials. It is unique for that Oauth access request, it expires, and it can be refreshed or revoked individually. You can get more than one and then give different ones to different 3rd party apps.

I did not test more than 2 tokens at the same time, but the API happily let me create two, use them both, and then later revoke one of them while the other continued to work. Read a few posts above. The posts before me had the links to the API and the RFC.

This is exactly what would be happening if you logged into the app from 2 of your own devices, each one gets its own unique token.

 

[f205v]

@darth_vad3r
Thank you for your explanation, but I have a different experience.
I DO know what a token is and I'm not mixing it up with ID.
I do generate my own tokens directly from Tesla's website (no middleman!) and use it in the few apps that let log in with token instead of user/pass (which I will NOT share, ever!). And whenever I generate a new token the old one gets automatically revoked; or at least it happen up to the last time I did it 3-4 weeks ago.
If anything has changed in the last 3-4 weeks, I'm not aware of it.

 

[darth_vad3r]

@darth_vad3r
Thank you for your explanation, but I have a different experience.
I DO know what a token is and I'm not mixing it up with ID.
I do generate my own tokens directly from Tesla's website (no middleman!) and use it in the few apps that let log in with token instead of user/pass (which I will NOT share, ever!). And whenever I generate a new token the old one gets automatically revoked; or at least it happen up to the last time I did it 3-4 weeks ago.
If anything has changed in the last 3-4 weeks, I'm not aware of it.

I don’t know about 3-4 weeks ago since my hands on experience with the API only started last night after months of pondering it. This thread helped me get going on it again. But there are posts discussing revoke older than 4 weeks.

Last night I generated a 2nd token and was able to use both. I didn’t refresh the first one. I tested refresh and that revoked the prior one it was linked to, but when I actually got “revoke” to work, it only revoked the single access token I told it to (used the same one as bearer and as token field, didn’t try revoking a diffferent one yet).

What method did you use to generate a new one that revoked the old one?

 

[markb1]

@darth_vad3r
Thank you for your explanation, but I have a different experience.
I DO know what a token is and I'm not mixing it up with ID.
I do generate my own tokens directly from Tesla's website (no middleman!) and use it in the few apps that let log in with token instead of user/pass (which I will NOT share, ever!). And whenever I generate a new token the old one gets automatically revoked; or at least it happen up to the last time I did it 3-4 weeks ago.
If anything has changed in the last 3-4 weeks, I'm not aware of it.

I don't think generating a new token (using login credentials) revokes the tokens for other sessions, because that would prevent multiple people using the official Tesla app on the same account, and I know that works.

I have in the past observed refreshing a token will revoke the old one, but @darth_vad3r says above that that doesn't work, so maybe something has changed. EDIT: Or maybe I don't understand what he means, in light of the previous post.

 

[darth_vad3r]

I don't think generating a new token (using login credentials) revokes the tokens for other sessions, because that would prevent multiple people using the official Tesla app on the same account, and I know that works.

I have in the past observed refreshing a token will revoke the old one, but @darth_vad3r says above that that doesn't work, so maybe something has changed. EDIT: Or maybe I don't understand what he means, in light of the previous post.

Sorry for the confusion, I think you are referring to this:

I had gotten refresh_token working and was going to rely on that to revoke the original token, but that still leaves a valid token around.

That is confusing. What I meant there, was that as a pure replacement for "revoke", "refresh" was a poor alternative, because it "still leaves a valid [NEW refreshed] token around". Theoretically nobody has it, but, if you just want to revoke a token you've given to someone, why replace it with a new one when you can simply just revoke it.

To be perfectly clear, revoke works. Refresh works too, and it revokes the one that gets replaced.

 

[markb1]

Sorry for the confusion, I think you are referring to this:


That is confusing. What I meant there, was that as a pure replacement for "revoke", "refresh" was a poor alternative, because it "still leaves a valid [NEW refreshed] token around". Theoretically nobody has it, but, if you just want to revoke a token you've given to someone, why replace it with a new one when you can simply just revoke it.

To be perfectly clear, revoke works. Refresh works too, and it revokes the one that gets replaced.

Got it. Thanks for the clarification!

 

[darth_vad3r]

Got it. Thanks for the clarification!

No problem. The API docs can be a bit lacking. They are great considering they are reverse-engineered and crowd-sourced

... but one reference didn't mention 'revoke' at all ... so I was trying to roll-my-own "revoke" using refresh (which worked with the downside of leaving the newly refreshed token 'out there'). When I found the one API reference that did actually mention revoke, it didn't work as they had documented it

Piecing it all together with the available API refs and this thread, you can get it all to work (or re-derive solution yourself as I did using API refs and RFCs )

 

[f205v]

@darth_vad3r
Thank you for all the info!
I'm using a method explained here (I'm nerdy, but not really a programmer, so I follow instructions but if something doesn't work I'm stuck!)
Tesla API Token Generator

Then I'm using the generated token in 2 apps: TeslaFi and ABRP.
When it happens that one of the apps asks for a new token I generate a new one, put it into the APP, and immediately I'm forced to put it also into the other APP; otherwise it will not work anymore.

maybe I'm doing something wrong, but this is my experience: I can only have one token at a time.