Getting Oauth tokens for the API

[wayner]

What is the proper practice for tokens - should I store a token locally in a text file and only try to get a new one if that fails, or is it fine to just get a new token every time you want to use the API? I may be running something every five minutes to check on the status of the car. Do I really want to get a new token every five minutes?

 

[ReturnZero]

The tokens are valid until you change your password, IIRC. You can just store it and use it. I would not get a new token every time.

 

[wayner]

Ok, but it seems like some of the libraries written, such as the Python teslajson get a new token every time you call the Tesla API. There is some discussion on the github library on a closed issue regarding saving the collection with pickle.Does anyone know how to do that.

The code gets a bit trickier as you have to retrieve the token and then figure out if it is still valid. If not then you have to retrieve a new one.

 

[wayner]

Anyone have a methodology for the Flow-chart to check for the validity of a token? Sure this is something that would be pretty standard for other devices that use a similar authentication methodology.

Does this make sense?

1. Retrieve stored token.
2. Test token by getting list of vehicles.
3. If response is 200 then you are good to go - exit with success code.
4. If response is not 200 then try to retrieve a new token.
5. If token retrieval fails then abort and exit with fail code.
6. If token retrieval is good then retry getting list of vehicles.
7. If response is 200 then you are good- exit with success code.
8. If response is not 200 then abort and exit with fail code.

 

[MagicMagicD]

When I had a quick look the other day it looked like a fairly normal OAuth implementation. You get an access token and an expiry time in second along with a refresh token which can be used to get a new access token without needing user credentials again (unless the password was charged).

Standard practice is to make your required API calls so that 401 responses cause a re-authentication, followed by a retry of the original operation.

You shouldn't need to 'test' the token with any given API - you'd just be adding additional network overhead to find out something you can find out by calling the API you're actually interested in.

 

[wayner]

Thanks - the reason that I had for testing the token is that then you don't have to trap for 401 returns (or other bad returns) when you are trying to do your real "action".

Would a 401 return be unique to expired or invalid token, as opposed to other types of errors, like malformed HTTP PUT or GET?

 

[MagicMagicD]

Would a 401 return be unique to expired or invalid token, as opposed to other types of errors, like malformed HTTP PUT or GET?

Yes, each HTTP status code reflects a specific issue, e.g. 400 (Bad Request) should be returned for malformed requests, 401 (Unauthorized) when your token has expired, etc.

In practice it depends how Tesla's developers have implemented the API as no-one can force them to send the correct responses - best idea in lieu of any official documentation would be to try a few edge cases to see what response you get and program accordingly.

 

[MagicMagicD]

Ok, but it seems like some of the libraries written, such as the Python teslajson get a new token every time you call the Tesla API.

This is perfectly valid, albeit lazy and bad from a security standpoint. Each access token gives you full access until it expires, so if 20 requests are made, that's 20 tokens that could grant someone access to your account if they were exposed somehow.