Duende IdentityServer is a protocol engine and framework and does not include any UI. When it comes to UIs around your authentication workflow, we designed this to be an extensibility point, and our Quickstart UI gives you a very good starting point for your own implementation. When it comes to Admin/configuration UI capabilities, we always deliberately excluded that from the product. There are many different scenarios and approaches how you might want to integrate configuration/administration of IdentityServer in your system.

I am happy to announce that we have finished all the work on version 6 of IdentityServer! IdentityServer v6 is fully optimized for .NET 6 which is a long term support version and thus an ideal platform for your updated or new identity infrastructure. Just like .NET 6, we will support IdentityServer v6 for the next three years. What’s new From a high level point of view we did: Performance and stability improvements.

One of the most exciting aspects of turning our IdentityServer project into a real company is, that we are now in the position to employ people and get them work in a field they are passionate about. And that is especially true if these are people you highly respect and always wanted to work with! Damian Hickey is an old friend and joined our team to help us with consulting, training and software development.

Two years ago, we decided that we need to find a sustainable business model for IdentityServer to ensure longevity and the ongoing work that is needed for such a larger scale project. There are various business models on top of FOSS like “open core” where you sell commercial add-ons, or building a support/services organization around it. None of those aligned with our long-term plans. After several discussions with various people, we came to the conclusion that for our case this will just not be possible with a typical OSI approved license.

While our V6 release is mostly about performance, stability and updates for the .NET 6 long term support version, we added one big feature: CIBA (Client initiated Backchannel Authentication). The Problem “Traditional” OpenID Connect authentication flows make the assumption that the client application and the “login page” are executed on the same device. For example, a user uses a web app in a browser, and that same browser is redirected for the user to login at IdentityServer, and this all takes place on the user’s device.

One of the most exciting aspects of turning our IdentityServer project into a real company is, that we are now in the position to employ people and get them work in a field they are passionate about. And that is especially true if these are people you highly respect and always wanted to work with! Anders Abel (we also often call him Mr. SAML) joined our team to help us with consulting and training and whatever the future will bring.

Back in March we posted our thoughts on the ongoing browser changes and how we think browser-based applications should be secured going forward. We also introduced Duende.BFF which is a pre-packaged solution for building BFF hosts using ASP.NET Core. In essence Duende.BFF has all the building blocks you need in one place to satisfy the needs of a BFF-style architecture: OpenID Connect & OAuth 2 client library Session management including server-side session storage Primitives for starting, stopping and querying sessions Support for back-channel logout notifications Built-in token management, e.

This is the fourth 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 Every login workflow is different. In some cases changing some colours and a logo is sufficient, but in most cases more modifications are necessary.

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.