IdentityServer VS ASP.NET Core

Its deprecated in favor of Duende Identityserver which introduced a license model.

Tokens usually have a lifetime and they are separate from the user's authentication principals like username and password. Unless you are rolling your own form of token provider (not something that would be recommended) the token creation is handled for you. Take a look at https://identityserver4.readthedocs.io/en/latest/ or if your organization makes under 1M in income a year the free version of what Identity Server progressed into https://duendesoftware.com/products/identityserver

I think Duende (Identity Server) handled the situation pretty well.

https://duendesoftware.com/products/identityserver

> Standard License Pricing

Thanks for your message. No, the idea was not to re-implement OAuth nor OpenID stuff. What I had in mind for the authentication thingy was something like this: https://laravel.com/docs/9.x/sanctum. If we want to go the OAuth/OpenID way, in .NET we have this one: https://github.com/DuendeSoftware/IdentityServer.

> As you said, there are plenty of local options that you only need to run.

I think managed databases are a good analogy here. While I might run my own PostgreSQL/MariaDB instance, many out there won't be overjoyed at the idea of actually needing to run and manage the damned thing, as well as set up some kind of alerting and handling the need to eventually scale it up.

> It also has the largest risk of compromise and data leaking from any service you may use...

PII is definitely a big concern, even if something like password hashes aren't too useful on their own (provided that they're salted), though in cases like that it might actually make a lot of sense to utilize a widely used and tested solution that's specialized for this particular use case.

In many cases, thousands of people across the globe will be able to develop something and squash any bugs in it better than you might be able to do individually or with your own team, though there might be a few exceptions out there. Auth is probably not one of the cases where you want to write code without a lot of eyes on it.

> ...the largest amount of potential lock-in...

This is debatable: standards like OAuth2 and OIDC technically make many of the solutions and libraries way more pluggable and make it easier to choose between various implementations, depending on your needs.

Of course, something like Keycloak also has its own API (as do many of the cloud offerings) so if you build too much automation around a particular implementation, then that advantage partially goes out the window.

> ...and the least need for integration.

I'm not sure about this, it probably depends on your architecture. If you have a monolithic web app, then you probably don't need a separate turnkey/SaaS solution, whereas if you have an ever growing number of services, whilst you want to manage authentication and accounts against all of them centrally, then something like Keycloak (or one of the cloud alternatives) become way more lucrative.

That said, I'd still opt for self-hostable options whenever possible, albeit I also don't trust cloud based password managers and such, preferring something like KeePass instead. I've probably just come to a different conclusion in regards to usability/responsibility/features/security than some other people.

Sadly, there aren't that many good options out there at the moment, apart from Keycloak. For example, IdentityServer is promising, but went in a commercial direction: https://duendesoftware.com/products/identityserver#pricing

He's referring to IdentityServer 3/4, which was open sourced, and was not owned by Microsoft. That 3rd party is commercializing their work (and to be fair, it's a lot of work) as https://duendesoftware.com/products/identityserver , and has a different commercial licensing model.

https://github.com/DuendeSoftware/IdentityServer/blob/main/L... does not seem to square with any definition of "open source" I'm familiar with, and that goes double for having an in-repo file that just says "read this unversioned pdf on some other site"

I would not recommend it. There is a server named Duende identity server which you can host locally.

> Just .GetAwaiter().GetResult() it.

That won’t work with various synchronization contexts, where doing this would cause a deadlock. There’s not much fun in trying to debug such issues.

And now that various libraries only provide async api, or worse an non-async version wrapping the async one with . GetAwaiter().GetResult(), you’ll be in for a treat updating your dependencies.

Async all the way is the answer, although various frameworks still don’t offer async hooks. Recently I ran into this for example trying to write an async validator in blazor, but that’s not possible and you have to work around it [1].

C# 5 introduced async/await almost 12 years ago. And we’re still not “async all the way”.

[1]: https://github.com/dotnet/aspnetcore/issues/40244

This approach to organizing middleware enhances code readability, maintainability, and reusability. By following this encapsulation pattern, you're adhering to best practices in ASP.NET Core development, ensuring your application remains well-organized and scalable.

🌟.NET 9 Preview 2 ➡️.NET 9 Preview 2 Discussion ➡️ASP.NET Core updates in .NET 9 Preview 2 ➡️ASP.NET Core updates in .NET 9 Preview 2 Release Notes ➡️EF Core updates in .NET 9 Preview 2 ➡️.NET Aspire preview 4 - .NET Aspire

https://github.com/dotnet/aspnetcore/issues/50643

Even if you look at Microsoft’s by far most popular GitHub project, they’re still only half as big as SupaBase. If you believe “the SupaBase story”, SupaBase grew and became twice as large as Microsoft in 3 years. Below is their likes over time if you’re curious, together with a couple of additional “too good to be true” Silicon Valley projects.

https://github.com/dotnet/aspnetcore/issues/10117

To achieve these objectives, we will take inspiration from ASP.NET Core Identity's PasswordHasher class. It incorporates a concept of hash versioning, allowing only the number of iterations to be modified.

yes I watched several courses, may be aim not getting clearly. but i worked with asp.net which uses http call and firebase cloud function also which uses socket connection, for socket connection its makes sense to use observable bcoz there streams of data we can observe once the connection establish ,but for http it need to be call every time.