Use system browser for login and redirect back to app (for Fleet-API)
Opened this issue · 9 comments
For the new Fleet-API, wouldn't it make sense to let the system browser (i.e. Safari) handle the login process and then use a registered app URL scheme to redirect (see redirectURI) back to the app?
With an in-app web view (TeslaWebLoginViewController) the end user still has to fully trust the app, whereas in the browser, the user can check the validity of Tesla's domain certificate.
(Disclaimer: I am only just starting with TeslaSwift, so please bear with me if I am requesting something that is utterly impossible or already present.)
But it's not already implemented in the TeslaSwiftDemo app, is it?
This line
let redirectURI = "teslaswift://teslaswift"
looks a bit like an app URL scheme, but I could not spot any Info.plist entry nor code that would actually handle it.
If it's possible (with the new fleet API), then I would strongly suggest to take this approach - also see the Oauth2 recommendations here https://www.oauth.com/oauth2-servers/mobile-and-native-apps/ and here https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uris-native-apps/.
I need to check but i think it is possible. right now it is not working because the lib is forcing the webview for login
I spent some time tweaking the code myself, and I basically got it to work with Safari - however, the whole fleet-API scheme is kind of flawed, as it exposes the client secret when the process, which is designed for web services, is used with a native mobile app on a device that the end user controls. See my remark (and Tesla's answer to "stay tuned") here: teslamotors/vehicle-command#170
Tag 11.0.0 now supports native browser login. Check the README for instructions on how to use it
I will keep this issue open until Tesla provides a better API
btw this exposes your clientID not your clientSecret, which is kinda ok
The app contains both ID+secret and sends both over the network in order to request the tokens.
So either the app binary can be decompiled (tricky) or the network traffic can be analyzed (very easy using Fiddler or HTTPToolkit as man-in-the-middle SSL proxy). Just to be 100% sure, I successfully tried the latter with several Tesla apps from the AppStore before I filed the issue to Tesla. The issue is even described in the RFC standard, so it's not really a spectacular discovery. The problem is simply that the secret is stored on a user owned device instead of a developer owned web server.
But thanks for updating the library (have not tried it, yet, though) - I think using an external browser (where certificates can be checked etc.) is important to earn the app user's trust. Now Tesla has to do its homework and update the scheme for secure use with mobile apps.
I think that any API that you call can be seen anyway because you can always tap into the connection via a local proxy. Unless someone uses SSL pinning.
Even if you can get the token from Tesla in your fake app, you would not be able to send encrypted commands anymore as you dont have the private key.
Oh and the callback would not work either. So not sure how one would automatically get the code