Usage with ASP.NET Core MVC?

[jnyeage]

I've been trying to use this in an ASP.NET Core MVC application. The problem seems to be that there is no WebView control available in .NET Core.
Would it be possible to run through the web-based authentication flow from an MVC app? I'm a noob to MVC. It's not a problem to redirect to the Tesla login URL, but getting /void/callback? value is what I'm not sure how to accomplish in MVC.

Any ideas?
Thanks.

[tomhollander]

Hi @jnyeage -

Unfortunately I don't believe it's possible to use the web-assisted auth flow from a website not controlled by Tesla. This isn't an ASP.NET limitation, but a consequence of the iframe sandbox security mechanism. A web page can embed the Tesla auth page in an iframe, but there's no way it can read the contents of the frame.

The "headless" auth flow should work, but only when no CAPTCHA is displayed - and from what I've heard it's back.

Tom

[gingertez]

Recently Tesla have made their API public and the web assisted flow should be possible from within a browser. I'm just playing about with this now with an ASPNET Core project and will report back.

[gingertez]

So - after playing around with it this afternoon... There are a couple of challenges that might need changes to the library's code.

I have managed to get the cycle to complete, with MFA, of my app's web page directing the user to the Tesla login and then when the login is complete, and the user has accepted the access requirements, my callback URL is called.

However, because I've added the TeslaAuthHelper as a transient dependency in my ASPNET Core services the code_verifier is different at this point and Tesla responds (correctly) saying it can't verify the code.

So... step by step:
(1) User goes to my account linking page
(2) My "code behind" in the page instantiates (via dependency injection) and uses TeslaAuthHelper.GetLoginUrlForBrowser() to generate my URL - which includes Code Verifier number 1
(3) Then I direct the user to the login URL
(4) On return to my callback URL the query parameters have a code in them... my code instantiates (via DI again) and uses TeslaAuthHelper.GetTokenAfterLoginAsync() to get the token - this method makes a POST call using the code and supplies a Code Verifier as part of the POST. Unfortunately the Code Verifier used here is not the same as the one used in step (2) and so Tesla failed to validate the code and return the token.

I'm not sure I want a singleton of TeslaAuthHelper ... is it a problem if all requests from my site to Tesla auth are using the same code verifier and the same state? I think the answer is "yes" because it makes it easier for people to intercept and spoof.

I haven't checked whether there's the ability in the TeslaAuthHelper library to supply an optional code verifier to reuse for the GetTokenAfterLoginAsync() method. But if not then that would probably be the change I'd make.

[tomhollander]

Did you look at the Test.Web sample app? I can remember how I addressed the challenges you mentioned but I did get it working.

[gingertez]

Hi @tomhollander - at a quick glance it looks like you used a static singleton (https://github.com/tomhollander/TeslaAuth/blob/master/Test.Web/TeslaAuthSingleton.cs) which will definitely work in dev/testing but in production will have some challenges:
(1) the query parameters are visible to the user - and so the "random" state and code verifier values end up the same for every user (if I'm reading the TeslaAuthHelper code correctly) which then in turn enables nefarious reuse of those.
(2) If I setup my deployment to create 2 pods (for load balancing) for my service/website on Azure or Google Cloud and the user gets routed back to a different pod for the /callback then there's no way to join up the state and code verifier to the original request and it will always fail.

What I'm considering is to add overloads for GetTokenAfterLoginAsync() and ExchangeCodeForBearerToken() with signatures like:

public async Task<Tokens> GetTokenAfterLoginAsync(string redirectUrl, string codeVerifier, CancellationToken cancellationToken = default(CancellationToken))

private async Task<Tokens> ExchangeCodeForBearerTokenAsync(string code, string codeVerifier, HttpClient client, CancellationToken cancellationToken)

And then route to the correct overload based on whether the call came in via the original or the new overload. Obviously minimal code duplication. but I think this will solve the challenges for security and multiple deployments.

In my own app I'm already storing the state generated by GetLoginUrlForBrowser() in a database so that I can retrieve it and match it to the original request when it comes back from Tesla so I'll also store the code verifier. I'm also tempted to make the loginInfo field accessible so I don't need to parse the returned URL (from GetLoginUrlForBrowser()) to get the state and code verifier values from the query parameters.

[tomhollander]

Thanks @gingertez for the explanation. Sounds like a good direction... If you can make these changes without breaking the existing contract (which it sounds like you can) please make a PR and I'd be happy to include in the library.

[gingertez]

I've made the changes locally and it works for my webapp (using the new overloads) and for my Windows app (using the old contract).

I've cloned your repo locally and done all this in a new branch but (understandably) you've locked down any random Github user from pushing new branches. Let me know how to share the code with you - happy to create a temporary fork if that's the route you want to go down... but adding my GH user temporarily to your list of users allowed to create branches, push code, and create PRs might be an easier option too (based on how paranoid you might be 😄 ).

[tomhollander]

I believe it's possible to raise a PR to merge from a branch in your fork back into my repo? That's what others have done in the past, e.g #33

[gingertez]

Thanks @tomhollander . I've done it that way - pull request: #39

[tomhollander]

I've merged the PR and published version 3.2.0 of the library to Nuget. Thanks for your contribution!