-
Notifications
You must be signed in to change notification settings - Fork 25.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blazor WebAssembly With Identity same-site coverage #31389
Comments
🎉🥳 Happy New Year! 💃🕺A green dinosaur 🦖 will be along shortly to assist. Stand-by ........ |
Thanks @julioct ... This is the main repo that we work from for general coverage.
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 ... 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. ☎️ |
Thank you @guardrex. But then, if the guidance leads this scenario into using OIDC, what's the point of the entire BlazorWebAssemblyStandaloneWithIdentity sample, where the idea is to use ASP.NET Core identity? How would you and @JeremyLikness recommend deploying this to Azure? |
Oooops! 😆 ... I misinterpreted "external" when I looked at it the first time, and I failed to realize that the "cloud ... server" isn't the host of the app in that context. By "external apps," they mean apps not under your organization's control. Interpreting it correctly 🙈😄... you end up on ASP.NET Core Identity. The next decision point, SSO, makes sense. For features like SSO that Identity can't provide, you end up on a non-ASP.NET Core Identity IdP, such as Azure Entra Id. I still don't think that you did anything incorrectly. I think you're good. @JeremyLikness will be along in a bit to laugh at me (again! 😄 ... security isn't my favorite subject to write about) to assist with what we'll add on using different domains (samesite settings) and any other gotchas 😈 that he's aware of. |
NOTE TO SELFI was going to track it separately, but this is a good item to include along with samesite updates. I need to get the reasoning for no CSRF/XSRF protection on Identity endpoints into this doc's coverage. The reason is explained in Jeremy's remarks here ... |
Hi, if it is just that app then using Identity and deploying it should be fine. If you were integrating with other apps, using it for single signon, etc. I'd suggest OIDC. This scenario should be fine ... this is basically like the older ASP.NET Core-hosted Blazor WASM scenario only you're serving the client bits from the static website. |
Thanks @JeremyLikness ... This is another one that I'll work on after I get the BWA+OIDC article written. I'll reach this one (and the other issue) either the end of this week or early next week ... I hope! 🤞🍀🗻⛏️😅 |
Thank you @JeremyLikness . |
UPDATE (2/7): This is on hold because we're still waiting for review and merge of the "roles" PR and work on the doc to explain how roles are handled. After that's cleared through, I think we'll want to have the code and article start with a lax same-site policy, which I believe is the default, and have the guidance on loosening it up for cross-site/domain requests per this issue. I'm not sure how much longer it will take to get the roles bit cleared through, but this issue will be next for the article+sample. |
Changing the title to reflect what we'll use this issue for. Blazor WebAssembly With Identity same-site coverage |
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:
The apps work mostly without issues in Azure, but I did have to add this to my API for cookies to work properly:
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
The text was updated successfully, but these errors were encountered: