Document the MFA login path

[timdorr]

As per the new auth system in #260, there is now a login path for users with Multi-factor Authentication (MFA) with a Time-based One-time Password (TOTP). I have already implemented this in the Ruby library, but this should be documented to help others in different languages/frameworks.

The basic gist is this:

• After POSTing your email/password to /authorize, if you get back a response with an HTML passcode field, you need to validate an additional factor (the TOTP code).
• GET /authorize/mfa/factors with a transaction_id from the /authorize page to list known factors on the account.
• POST to /authorize/mfa/verify with the transaction_id, factor_id of your factor, and the current TOTP passcode.
• This will validate the current transaction_id and allow the previous /authorize request POST successfully with transaction_id as a form body parameter.

Should be pretty simple to add to the docs. I've just been lazy...

[tbee]

Right. It seems the process was changed. Has anyone figured out what? I see more v1 in the URLs and a GET to an openid-connect/generic, but my login process is already failing prior to that request; it fails in the GET /authorize/mfa/factors

[ryphez]

Tesla integration asked me to reconfigure and it isn't prompting for any MFA. Should that code be run in the reconfigure path as well?

[tapizquent]

Any updates on this?

[tbee]

Yes. Tesla has added a recaptcha to the login process. If you're examining an automated process, chances are high you won't see it, because it loads with a delay in a iframe. This is an image like "select all squares that show traffic lights", impossible to automate.

The only viable approach seems to be to run the login in an embedded browser, at least that is what ABRP has done to solve this: registration is only possible in their mobile apps, which monitor a webview.

For my API implementation in Java I have still not been able to use an embedded browser, because Java's webview uses native calls to a browser engine (webkit), and I cannot examine the two consecutive redirects (which contain the all important authorization code). Only the request before and the response after :-/ Work in progress.

[core-hacked]

@timdorr Maybe it's time to close this issue? It was documented in the recent PR #666 😄

[timdorr]

Yup, thanks!