Blazor WebAssembly With Identity same-site coverage

[julioct]

Description

After going through the BlazorWebAssemblyStandaloneWithIdentity example, which works great, I want to make sure ASP.NET Core Identity with Cookie Authentication is still the right choice after deploying this to Azure.

Specifically, I have deployed my apps, following the approach in this example, like this:

• Blazor WASM standalone app hosted in Azure Static Web App (https://brave-field-0f649a310.4.azurestaticapps.net)
• ASP.NET Core API hosted in Azure App Service (https://gamestore01.azurewebsites.net)

The apps work mostly without issues in Azure, but I did have to add this to my API for cookies to work properly:

builder.Services.ConfigureApplicationCookie(options =>
{
    options.Cookie.SameSite = SameSiteMode.None;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});

I want to make sure ASP.NET Core Identity is the recommended approach in this scenario, as opposed to using an OIDC server. I went through the guidance on this official doc and after following this diagram:

...it is not clear to me if my Blazor WASM standalone app, which lives in Azure Static Web App, should be classified as external or internal, which is the first decision point. I own both the API and the Blazor app, but it's not like they live in the same domain (given the different URLs provided by App Service and Static App).

Could you please clarify if the approach in the BlazorWebAssemblyStandaloneWithIdentity sample is recommended when deploying to Azure App Service + Azure Static Web App?

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/standalone-with-identity?view=aspnetcore-8.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/security/webassembly/standalone-with-identity.md

Document ID

c4e6ec41-7bea-e600-6473-c5c870aab082

Article author

@guardrex

[github-actions]

🎉🥳 Happy New Year! 💃🕺

A green dinosaur 🦖 will be along shortly to assist. Stand-by ........

[guardrex]

Thanks @julioct ... This is the main repo that we work from for general coverage.

The answer to your question is ... yes, it's external (to your organization, given that you're cloud hosting it in Azure) ... and since you implicitly indicate that you placed the backend on the cloud (i.e., Azure), the answer to the question about being required to store user data on your own server is implicitly no, so you end up on the cloud/managed OIDC endpoint of the diagram (e.g., Azure). WRONG ... sorry ... I looked tooooo fast. "External" is external to the organization's control, and the IdP provider isn't the host. Those diagram endpoints for other OIDC providers, such as Azure Entra Id, are for when ASP.NET Core Identity can't meet the spec, such as for SSO.

The samesite cookie setting is part of an existing ... well ... I was going to say "issue" ... but really it's part of just a remark at this time from Jeremy. See what he wrote at the end of ...

#31205 (comment)

Let's use this issue to cover that aspect. I should've opened an issue from his comment anyway.

Let's ping Jeremy to look all of this over, and I think he's going to say that you're good ... you've done the right things. He'll let you (us 😄) know if there are any gotchas 😈 to watch out for or other required configuration. He'll indicate what sort of guidance to add for the different domains (samesite settings) scneario. Based on what he provides, I'll set up a PR to enhance the coverage.

Paging @JeremyLikness ............ Mr. Likness ... Mr. Likness ... Please pick up a courtesy telephone. ☎️