Also, .NET loves leaving core features to paid/freemium third parties/cloud instead of offering it as a first class open source component. It makes it hard to justify buying into the ecosystem when it's a blatant funnel. Just look at how they do their OAuth:
All cloud/paid solutions. At one point they were all in on open source but the tune quickly changed when they saw how much profit they were leaving on the table.
> At one point they were all in on open source but the tune quickly changed when they saw how much profit they were leaving on the table.
Correction: At one point they said they were all-in on open source - 10 minutes after creating an innovative new open source product called ".net core", which is exactly like .net, but with all of the features you might actually be interested in stripped out.
Nobody in my circle talks about .net because we all saw immediately that it was just the same act again, if somewhat less openly hostile than Microsoft's previous MO.
But the things they stripped out that you say were "ms-specific" were only "ms-specific" because they didn't bother to port them along with the rest of core...
...And as a result, core didn't contain anything interesting, and there's no reason you'd use it.
OAuth is an internet standard and you can write a client in literally C if you in any way know HTTP, and I do mean YOU can do it.
I haven't been very deep in the .net ecosystem but haven't had any issues implementing an api woth auth and rate limiting etc using dotnet and nothing Microsoft licensed.
For a small/solo team, which is the audience under consideration, they probably want to spend their time on their core product and not reimplementing oauth.
I'm not saying they need to reimplment it. My argument is that it is absurdly simple in any batteries included stack to do OAuth even without specific support, not that .NET doesn't have a multitude of open source implementations that isn't what OP mentioned.
It's an API call to an external provider and like 2 endpoints on your side. If this doesn't take you at most a few hours to implement yourself then I don't think you should be relying on a library in the first place, go implement it in your spare time. Then you can use the library with your new found understanding of how absurdly easy it is.
Maybe you will learn about implicit flows and how OIDC would allow you to validate JWTs and never have to write a single line of server code to deal with OAuth.
Maybe you will learn about SCIM[1] and all the interesting stuff related to auth that you never bothered learning because the library does that. Maybe the business that is paying you would prefer SCIM + SAML/OIDC but you could not even begin to discuss is because your library doesn't do that.
To be more precise: MS loves to make you think you need those, see also WebSocket support. But in reality you don’t need that, if you know what you are doing. Also don’t implement your authorization server folks, at least when possible.
https://learn.microsoft.com/en-us/aspnet/core/security/authe...
All cloud/paid solutions. At one point they were all in on open source but the tune quickly changed when they saw how much profit they were leaving on the table.