-1

I am currently developing in a standalone (Not .Net Core Hosted) Blazor WebAssembly app in .Net 5.0. I have been trying to convert a couple Asp.Net MVC WebAuthn examples over into my Blazor app for Passwordless Authentication.

The issue I am experiencing now is due to this app's architecture since it is not a Blazor Server app. The Asp.Net MVC example I am following has everything including the client hosted on the server whereas my app is split Web Client/ Web API architecture.

So far however, I have managed to get most of the way through these differences but now the issue I am having is in the last functionality of registering the credential with the server within the Make Credential request of the Fido2NetLib Library. on line:

 // 2. Verify and make the credentials
 var success = await _lib.MakeNewCredentialAsync(attestationResponse, options, callback);

I am receiving an error saying: "Origin https://localhost:44325 not equal to original origin https://localhost:44309". Now of course this is a dev environment but it will be exactly the same in production as the API and the client are hosted in two different domains.

Any ideas would be greatly appreciated. I am hoping I can "white list" certain domains?

Anthony Griggs
  • 1,469
  • 2
  • 17
  • 39
  • Anthony, did you determine if it was impossible to implement WebAuthn with the type of 'split architecture' you describe in your question? If so, what did your solution look like? Since Apple just released iOS 16 with Passkey support, I'm trying to put together a demo project but I implemented everything as split architecture and then ran into the problem you described above. Kind of a bummer. Just thought I'd ask. – RangerRick Oct 11 '22 at 19:00
  • @RangerRick I ended up resolving my issue by migrating everything over into a .Net Hosted app... which put everything Client and Server side under one domain so as to eliminate this issue. Mackie commented below described a scenario which sounds right, but I wasn't sure how to implement it given my split architecture so I just took the easy way and went .Net Core hosted which also had several other benefits. – Anthony Griggs Oct 11 '22 at 20:27

2 Answers2

2

WebAuthn defines the origin to be the fully qualified origin. Per referenced RFC6454, this is the tuple of scheme, host, and port. You can't go breaking the rules without deviating from the standard.

Community
  • 1
  • 1
aseigler
  • 504
  • 3
  • 7
  • Thanks again. Not the answer I was hoping for but +1 for its accuracy. I changed the title to remove the Fido2NetLib since it is WebAuthn related only. – Anthony Griggs Apr 21 '21 at 13:46
0

WebAuthn gels very well with using a separate identity provider (e.g. something Open ID Connect/IdentityServer4-based) as the origin that deals with credentials will always be the same regardless of the relying parties involved.

mackie
  • 4,996
  • 1
  • 17
  • 17
  • Thanks for your reply. Maybe I am misunderstanding the issue but in my case the client is hosted in one domain a.com and the FIDO2 Server, Identity Server, and API is hosted on another server b.com. Am I missing something in my understanding? – Anthony Griggs Apr 21 '21 at 13:53
  • 1
    The point I'm trying to make is that really you need to ensure that the FIDO2/WebAuthn exchange only happens on a single host name and that if you have multiple client applications this dovetails nicely with having a single central (and front-channel browser-based) authentication provider. If your IDP is auth.b.com (and thus all WebAuthn credentials are tied to auth.b.com) then that doesn't then prevent app.a.com from authenticating and it means it does not have to worry about *how* auth is done just that it was. Apologies if I've mixed the crux of the matter. – mackie Apr 21 '21 at 15:58