This is the third part in a series of posts covering new (and old) features of Duende IdentityServer. These posts are not supposed to be super technical deep dives (that’s what documentation is for), but rather explain the feature at a more conceptual level, why it exists, and why it might useful for you. The Problem The authentication system in ASP.NET Core is designed to be configured at startup time. That’s where you add authentication handlers and their configuration to the DI container.

Writing a browser-based application is hard, and when it comes to security the guidance changes every year. It all started with securing your Ajax calls with cookies until we learned that this is prone to CSRF attacks. Then the IETF made JS-based OAuth official by introducing the Implicit Flow - until we learned how hard it is to protect against XSS, token leakage and the threat of token exfiltration. Seems you cannot win.

Every once in a while, a security problem comes up that needs patching. We couldn’t find a clear and concise Microsoft document that describes that process, so we asked Barry directly. We thought it might be useful to document our conversation here. Regardless what you are building, you ultimately have two types of dependencies: Functionality that is part of the .NET runtime/SDK Functionality you reference via a Nuget package. This might be a Microsoft package that is not part of the shared runtime (e.