[bobkazamakis]

>- Web framework is not quite on-par with Django/Rails. Particularly with auth/OIDC.

Completely wrong. Not only does Auth work particularly well out of the box, but microsoft documentation is top tier with both c# and asp net core.

https://docs.microsoft.com/en-us/aspnet/core/security/authen...

asp net core is the single best framework for backend web at this time, but yes, won't be as fast to ship as django/rails. If you like to maintain code, I'd consider it a worthy tradeoff.

[Guid_NewGuid]

Ah, fair criticism, thanks for educating me. To be honest I'm repeating barely-remembered experience from years ago now, time flies. I just always found documentation pushing to Azure AD, or the now paid IdentityServer stuff, when it comes to SSO.

The other thing that works against me in having a Django-like experience with web is I always switch away from EntityFramework as early as possible in favour of handwritten SQl. I think a fair comparison probably puts EF level with or ahead of Django.

But this auth documentation looks interesting and definitely an improvement.

[melony]

Their offical "SPA API Auth" involves paying for a third party OAuth server (called Duende IdentityServer, the ASP.NET Core built-in auth solution on the other hand is called ASP.NET Core Identity) and Microsoft refused to ship their own server because that would be "competing with the open source community" (there are multiple long Github threads on this which Microsoft product people would lock and mute). I wonder which PM got kickbacks for that decision. Originally Duende IdentityServer was free under Apache, and then they immediately turned into a paid solution after they became the "official" solution for API Auth. Microsoft also claims that standard cookie auth cannot be used for API Auth in a SPA scenario (their security engineers insist that you use JWTs), if you look through their Github issue threads, the ASP.NET Core engineers seem to believe that the default ASP.NET Core Identity generic cookie auth is for MVC only and it is "not recommended" for use with SPAs.

https://docs.microsoft.com/en-us/aspnet/core/security/authen...

https://duendesoftware.com/products/identityserver

They like to hide their dirty laundry behind clever developer advocacy teams and drowning it in Github bureaucracy but here are some examples:

https://github.com/dotnet/AspNetCore.Docs/issues/25832

https://github.com/dotnet/AspNetCore.Docs/issues/7644#issuec...

https://github.com/dotnet/AspNetCore.Docs/issues/24157

https://github.com/dotnet/AspNetCore.Docs/issues/18524

Their PMs are not building an open source product in good faith. As far as they are concerned, ASP.NET Core primarily exists as a funnel to send customers into Azure or buy stuff from Microsoft partner companies. Imagine if Vercel one day removes the standalone server hosting option and requires you to pay for their serverless cloud to use important features. This is what Microsoft is doing here right now with ASP.NET Core. If you lock your stack into their ecosystem, then be prepared to spend money either on redundant cloud subscriptions or developers reinventing the wheel on core features

[WorldMaker]

It's not Microsoft's fault that Duende took their ball and went home, becoming a closed source operation after years of open source work. That's on Duende for being bad Open Source community members.

I somewhat sympathize that Duende's unpaid support costs went up once Microsoft pointed a lot of heat their way by including it in official samples, and they should get paid for support. I also somewhat sympathize that closing their source was seen as the easiest option to redirect the community to paid support plans.

But it's still a jerk move in the Open Source community to have code be open source for more than a decade and then close it simply because it was used in one tutorial/sample too many.

Sure, Microsoft could have offered sponsorships or other help, had Duende asked. Supposedly Duende didn't ask, their first public response was when they immediately went closed sourced because apparently they never really cared about Open Source.

There are people not building an open source product in good faith in this story, but it doesn't seem to be Microsoft (surprisingly).

Microsoft probably should replace IdentityServer with something that actually wants to be good Open Source in the samples again. They are between a rock and a hard place because if they fork the last Apache versions of IdentityServer they look like the bad guy for "stealing" Duende's work at that point, and they can't resurrect their old code because it was bad. They probably have to wait for some third party fed up enough with paying Duende for bad faith Open Source to make their own fork.

[melony]

They don't have to fork anything, they can just add a built-in OAuth to ASP.NET Core Identity. They did that with JSON and created an in-house alternative to Newtonsoft's fast JSON library once it became popular enough. I didn't hear any PMs whining about "competing with the open source community" then.

[WorldMaker]

OAuth is too (stupidly) complicated for "just add a built-in OAuth to ASP.NET Core Identity". They had that in previous samples (which you can still find online if you look) and it was bad code that suffered from code rot and stopped being "OAuth compliant" especially with respect to even more (stupidly) complicated OIDC, so they looked for someone to maintain that and IdentityServer already existed and was OAuth compliant/audited. That's why it needs to be forked. Someone has to do the OAuth/OIDC hard work. Microsoft is paid to do that in other divisions of the company, of course, but it's all in Azure and they want you to pay for Azure AD alphabet soup that pays the bills for their OAuth/OIDC compatibility auditing.

> They did that with JSON and created an in-house alternative to Newtonsoft's fast JSON library once it became popular enough. I didn't hear any PMs whining about "competing with the open source community" then.

James Newton-King, the "Newton of Newtonsoft", was one of the developers involved in that project that decided a clean compatibility break with JSON.NET (which has been showing its age, but also has far too many users to easily break API compatibility) was necessary to achieve the performance goals that System.Text.Json was created to meet. That's not so much competition as it is cooperation.

[bpicolo]

Cookies work great for SPAs and I highly recommend the path for first party auth. Setting up CSRF tokens on the frontend is a lot easier than setting up OIDC.

[melony]

That's correct. And if you have configured SameSite corrrectly and your GET request handlers are locked down, you don't event need CSRF tokens. Unfortunately Microsoft ASP.NET Core security engineers' careers seem to depend on have differing opinions on how to secure SPAs and APIs.