Life After IdentityServer4: Open.IdentityServer with Andy Clymer

So Andy, welcome to the show. This will be the first interview of season nine. That’s it, and you can tell I’m already rusty. How are you doing, Andy?

Oh, I’m doing good. I’m doing good. Getting ready for autumn. So yeah, all good.

Nice, nice. The leaves fall and we get a new version of .NET. That’s the two things that happen in autumn, right.

So yeah, we are going to talk about IdentityServer stuff in a moment, but before we get started, I wonder, could you give the listeners a bit of an elevator pitch? A little bit about you, that kind of thing?

Yeah, absolutely, sure. My name’s Andy. I’m one of the founders of Rock Solid Knowledge. I’ve been programming since I was eleven. I had a ZX81 that my dad brought home from work and said, “we need to learn how to use this,” and I’ve been coding ever since. I’m now 55, so I’ve been around the block a few times.

I generally worked in small companies, and I ended up working at Cisco through acquisition; seven of us got bought back in the early 90s. After that I moved into doing training. I worked for a company called DevelopMentor, and we went all around the world teaching other developers how to build .NET applications, and visited Microsoft quite a lot, and various things. As a consequence of that, four of us left DevelopMentor and started Rock Solid Knowledge. That’s where it came from. We didn’t really know what we were going to do; we just knew that we liked working together, so we started a company. That was 17 years ago.

We ended up focusing very much on identity and security in the .NET space. So building a company that would create components for other developers to pick up and use to build their own security, identity, and access management solutions. Whether it be something like our SCIM component for integrating Entra with your application, so you get notifications ahead of time when people join the organisation or perhaps change roles. Or it could be using our components to build a single sign-on solution, or in some cases people go, “could you build a single sign-on solution for us?” So basically, a company that has lots of components around the security space that you could use to build something like that. That’s the space we ended up in.

As a bunch of four engineers starting a business, we didn’t have loads of business sense, but what we wanted to do was build a business that felt fair and good for everybody. So about three or four years ago we became a certified B Corporation, which puts you in the Ben & Jerry’s type of thing. You see that little B Corp logo on Fairtrade-type products. That really means that we are a company that’s not driven purely for profit. We care about the environment, we care about our employees, and we’re very transparent about what we do. That was quite an important thing for us.

But really, what we’re probably going to talk most about today is something that we’ve done in the last six months, which is launch something called Open.IdentityServer, which a free framework, and it’s free forever (that’s really important for us) for developers to be able to build a single sign-on solution around OAuth and OpenID Connect. We’re guaranteeing that it’s free forever; it’s part of our business model in terms of selling our other components that add on to that central offering, effectively.

Then finally, in terms of finishing off our journey, in 2024 we were acquired by a large organisation called Constellation Software, which I’d never heard of at the time. I realise now it’s probably one of the largest software companies in the world; there are about 2,000 companies in the group, and it buys mature vertical software companies. So the nice thing now is we’re backed by this very large organisation with a massive balance sheet, but we’re left to run the company in the same way that we’d have run it when we were a small company based in Bristol in the UK. So that’s fantastic from that perspective.

The nice thing as well is that Constellation Software are a “buy and hold forever” company, and that’s one of the reasons why we sold to them: they’re not going to asset strip or flip the company. So it creates a great platform for everybody that still works here.

Yes, okay. There’s a whole bunch of stuff to unpack there. Some of it is business-y stuff, some of it is programming stuff. I feel like maybe you and I had a similar start.

I just want to walk down memory lane. This isn’t going to mean much to the listeners, but one day my dad came home from work with a big box of stuff and said, “there’s a computer in there, you’re going to put it together.” It was an Amstrad CPC 464, which was like the poor man’s ZX Spectrum or something like that.

Yeah, I know it very well. Oh, I don’t know; it had a proper keyboard and a nice little integrated cassette deck. There’s a bit of nostalgia there for me too, right? I remember those machines. Yeah.

Yeah, yeah. Because most folks outside of the UK have never heard of them.

True. Yeah, yeah. It was a good ecosystem at that time. There were so many computers. Everybody in the playground had a different one, right? It could be a Spectrum, a Commodore 64, a VIC-20, a Dragon 32 if your parents didn’t love you, all those different models, right? TRS-80s, BBC Micros. I was fortunate enough to have an Archimedes as well. It was a great time, I think.

So there’s a completely different topic hiding behind this, but it makes me wonder whether we are a different breed of developer to those who came after us, because we started, not necessarily in the trenches, but adjacent to the trenches, right?

There’s this phrase that’s going around at the minute: “generation iPad.” I’ve seen it, one example that’s come up on the show before: a person in my family didn’t know how to print, because they didn’t know where the print button was, and they didn’t know where the print button was because they don’t know what a printer looks like, right? Which is unfortunate, and I’m not making fun of them, but the point I’m making is we’ve moved so far into the land of abstraction that we don’t need to… You and I will probably remember how to get a ZX Spectrum, or one of those older machines, into a position where it would load from a cassette tape. Then you have to hold down the play button and push a button to get it going, right? We know those things.

One of the first programming languages I learned (not the first, but one of the first) was assembly. On this particular device, every program had to end with TRAP #11 to be able to actually quit out and capture certain events on the way out. That was on a specific dev board, but I don’t need to do that, right? When we want to close our program in any software we’re writing, we just do a little squiggly bracket and we’re done, right? That’s the end of the app. We don’t have to do anything else. We don’t even need to do any cleanup, right? Because .NET does it all for us.

Yeah, exactly. It’s a very different world. I went through the whole 6502, Z80, and ARM assembler in those days. It’s a different way of talking to a machine, right? It feels very raw, you feel part of the machine, and it’s very rewarding when things happen. Working out how to draw a circle using eight-bit registers and stuff; it’s a different type of programming for sure.

But that’s not what we’re here to talk about. We are going to be talking about, like you said, Open.IdentityServer. This new… well, new to me, so it’s not new new, but new to me… this way of, like you said, setting up identity, OIDC, and all that lovely, wonderful stuff that we need in our apps.

There was an IdentityServer before: IdentityServer4, which is… I don’t want to say abandoned, but it is what it is. The devs behind it have stopped working on it. They’ve set up their own company and started their new journey with their own version of IdentityServer going forward, and that’s great for them. But I guess most people who have maybe done .NET Framework apps and done identity probably had IdentityServer4, or ID3 (IdentityServer3), or whatever, and they’re probably looking at this going, “but that still works. What the heck’s this all about?”

So I guess that’s a really roundabout way of asking: what is Open.IdentityServer, and does it relate to IdentityServer4? Does it relate to Duende and what they’re doing? Can we describe it in terms of that?

Well, that’s a great question. You’re absolutely right in terms of heritage. There was IdentityServer4, and prior to that, IdentityServer3; obviously different versions. They were all free, open source versions created by Dominick Baier and Brock Allen. IdentityServer4 got to a point where they decided that they wanted to take it away from a free model to a commercial model, and there were lots of good reasons behind why they did that.

So how does Open.IdentityServer relate? Duende.IdentityServer and Open.IdentityServer share the same heritage. They’re both forks, or continuations, of IdentityServer4. IdentityServer4 was very popular; it was free and open source. Duende then moved to a commercial licence, but built off the same code base. They weren’t looking to start again from scratch and relearn everything. I mean, they’ve done that a few times: IdentityServer4 was a rewrite of 3, et cetera. So Open.IdentityServer and Duende.IdentityServer share the same historical starting point, right? In that case they’re very, very similar. They start from the same point.

Duende has moved on quite a bit in the three or four years since IdentityServer4 stopped being maintained, and IdentityServer4 stayed on .NET Core 3.1, so it’s still running a very old version of .NET Core, and that’s now not supported. So Open.IdentityServer has done a recent fork, going back to about February of this year, and the goal of that was to make version 1 be a version of IdentityServer4 in terms of the features that it currently had, albeit on .NET Core 3.1, but updated to .NET 10. Perhaps more importantly, any security issues that were discovered between IdentityServer4 and the latest version of Duende, we’ve applied.

So from an end user’s perspective, if they’re using IdentityServer4 today, they’ve got an opportunity now to move to Open.IdentityServer, run on a supported version of .NET, have the security updates done, and put themselves in a position where they will get new features as we start developing them over time. So that’s how they’re similar.

Duende and Open.IdentityServer are fundamentally different in terms of commercial model. Duende is a commercial model: you pay a licence fee, and depending on the number of applications you want to support, the licence fee will change. Whereas Open.IdentityServer is free forever. We’ve made that statement very strongly, and we’ve got massive sign-off from our new owners that this is core to our business, and that’s why it will be free forever going forward.

The other thing that’s very similar is we made a decision to keep the database schema the same. A bit like an IBM clone, right? We’ve got AMD and we’ve got Intel. We’re using exactly the same schema for the database, so if you wanted to migrate from IdentityServer4 or Duende IdentityServer, you’re not going to have to deal with lots of database migration issues. We’ve gone for database schema compatibility from that perspective, and we’ve kept the APIs for the framework the same as well, again to make it super easy to migrate.

Let me check my understanding a little bit then. Let’s say Jamie has been building an app, previously using IdentityServer4. We’ve gone through the process of upgrading things from .NET Framework into .NET Core. I’ve had to stall on .NET Core 3.1, because IdentityServer4 is stuck there. I’ve looked at Duende IdentityServer and gone, “wow, that’s expensive.” Understandably so, because the companies that use IdentityServer and have made a boatload of money can pay a little bit towards its development, right?

So I’ve looked at Duende IdentityServer and gone, “that’s a little bit too expensive for me; maybe I’ll check out Open.IdentityServer.” I do whatever I need to: dotnet add package Open.IdentityServer, maybe (I’m making some numbers up here) half an hour of wiring up, just to remove certain using statements and what have you. And I can just hit go and it keeps working?

Absolutely, and we’ve had lots of customers do that. Someone at work coined the phrase that it could be a POC that you do during your lunch break. We’ve got videos online that show you can do it in about 10 minutes, but that’s a bit of sales video work. Clearly, with a major piece of infrastructure like this, you probably want to take your time and check everything out. But yeah, we’ve made it as easy as possible, and we’ve got customers who’ve just said, “yep, it just worked, no issues at all.” So yeah, it is relatively that straightforward. That’s mainly because we are coming from the same historical starting point, right? That makes a big difference.

Yeah, and it makes perfect sense to do that, because then your onboarding, like you said, is super quick. The canonical example people always give is “we’ve wrapped the DbContext in an interface, because what if we move away from Entity Framework?” And I’m like, “cool, yep, you can move away from Entity Framework if you like, but it’s a boatload of effort to do that.” “Oh, well, we’ve used Entity Framework and we’ve abstracted some other stuff in case we move away from SQL Server.” Excellent, but also that’s a whole boatload of effort, right? Up to and including maybe changing your data model.

So being able to swap out a pretty sizeable library of APIs and functions and services that gets me the new stuff, like you said, the security fixes and all of that, and support on, I guess, the latest version… Maybe not in 10 minutes like a sales video, but maybe half an hour or whatever, like on your lunch break. Or maybe, hey, guess what? Maybe you could have your agent do it for you. I don’t know. That makes it super easy for adoption rates. Then I can turn to whoever makes the decisions and go, “oh, you know that thing you told me to do? Well, it’s already done.” They’re happy, I’m happy, and the system isn’t down for any time.

The big thing with upgrading and replacing libraries and features and stuff is that it’s work that is costly, but it feels doubly costly, because if it works, nothing changes. The end user can still log in. It’s not like they can log in faster.

Yeah, exactly. We used to have the same phrase at Cisco: security is a necessary evil. It doesn’t sell any more widgets, right? But it’s something you have to do. I think making sure that your gateway, your single sign-on solution, your login screen is up to date, patched, and secure is super important, but it doesn’t necessarily look any different. So it can be a bit of a hard sell.

But we all know, especially in the day and age of AI being able to work out vulnerabilities, running on a stack that is supported and patched is super important. You don’t want to be risking the gateway to your application being vulnerable to an attack, right? So I think it’s more important than ever now that those things that we would probably see as not high value, from a generating-more-sales perspective, we still look after from a security perspective. More so now than ever before.

Oh yeah, absolutely. One of the things that I realised when I was researching some of the other episodes in this season is that out of support means out of support, right? It means if a CVE is generated, they’re not even going to mention whether the out of support version is susceptible to the CVE. This happens across the technology space; it’s not just a Microsoft and .NET thing.

But if we look at what was termed, earlier this year (2026), the worst CVE in the history of .NET [CVE-2025-55315, which was disclosed in October 2025], which was raised as a 9.9, it only flags on versions of .NET that were in support at the time. So you can run your security scanner, and if you were on an earlier version, like, I don’t know, .NET 6, your security scanner will say it’s all fine. But I can run a proof of concept that breaks into your system, because the security scanner is only based on what the CVE says, and the CVE is only reported for the things that are in support.

So yeah, you’re absolutely right: being in support is way more important now than it ever has been. I hate the phrase, but you don’t want to be caught with your pants down, you know?

No, exactly. We’ve had lots of people… even as far back as, I don’t know, maybe nine or ten months ago. I’m not going to mention who the company is in the scenario, but they were running IdentityServer3 as the main access. That went out of support such a long time ago; it was unbelievable. But again, it’s a login screen. It sits there and it doesn’t look broken, but the number of security vulnerabilities in it was huge. So yeah, you’ve just got to stay up to date.

That’s what we’re offering here with Open.IdentityServer: that opportunity for people who have bought into free open source, and who want to make sure that they’ve got a platform that is fully supported, to use, right? Some customers who’ve come to us recently actually did fork their own copy of IdentityServer4 and have been maintaining it, and now that we’ve picked it up, they’ve come to us and said, “well, we’ve done these changes. Would you be interested in adding them?” So other people have actually done it; they’ve got private forks. But now the nice thing is that, hopefully, as a community, we can produce a version that’s free and secure by having all that collective effort in maintaining it going forward.

Well, let’s talk about that real quick then. I’m going to use the wrong phrase, I think, but if I say “parent company”, hopefully everybody understands what we mean. The parent company has said this can be a free offering forever.

So what does that look like then? I’m a solo developer, I want to bring IdentityServer into my application. I can download the NuGet package, I can do the setup required, and my app is up and running. But then I’m also a developer who works at a massive enterprise making billions of dollars a year. I want to download the NuGet package, I’ll run through the setup process, and I’m set up.

In other ecosystems there’s sometimes an “oh, but if you’re an enterprise…” If we look at, say, Visual Studio, as a really poor example. There’s Visual Studio Community, which (please do your own research, folks; I don’t work for Microsoft, and I’m not saying Andy does either) within certain limits you can use for free. Then there’s Visual Studio Pro and Enterprise, where those limits are not there, because you are a professional or you work in an enterprise.

So, really badly formed question, but across the industry, across the smorgasbord of potential sizes of company, am I always just using it for free? Can I just install the NuGet package and I’m done? Or is there some caveat of “well, you’re a multi-billion dollar company, you can send a few dollars our way to help support it”? What does that look like?

Yeah, it’s a great question. I think it’s been the dilemma of lots of free open source projects. A bit like IdentityServer4, there was a lot of effort gone into that, and there was a feeling that large organisations were making money off the back of people who were giving up their time for free, and not actually donating back. That’s a real problem, right, in terms of how do you address that.

We see the framework, the core piece, as free forever. The reason we can do that is because we provide value-add components that go on top of that. The framework doesn’t come with a UI to manage the configuration, so we sell that. As a developer in a large organisation, you may decide, “well, that’s really important to us, so we’ll pay for that.” That then helps us to put money back into supporting a free platform.

We have a whole range of components, whether it’s things like automatic key rotation to change the signing keys on a regular basis, which is best practice. But if you want to use the framework for free and you’re happy to rotate the keys manually every 90 days, or write your own tool, that’s fine too, right? We’ve got components to support other protocols like SAML or WS-Federation. We’ve got other products to do things like SCIM. So our business model is this: we’ll give a framework away for free, with the idea that if people adopt it, they’ll want more than the free stuff, right? They can build on top of that. They can either write their own stuff, or they can go and buy a commercial offerings.

One of the things we launched this August was what we call our supporter licence. Whilst we have seven or eight products that you can license independently of each other, we wanted to find a way to let people declare their support for free open source as an organisation. Not buying us a coffee or donating us some dollars, but actually allowing them to purchase something which gives them extra value above and beyond the free. We want to reward people who contribute to us in terms of giving us some money.

So with the supporter licence, you pay an annual fee and we’ll give you access to all our products. That’s everything from key rotation, AdminUI, SAML, WS-Fed, Enforcer, SCIM, and we’re about to launch a backend-for-frontend component. All our components will be bundled as part of the supporter licence, and if a company’s willing, we’ll also advertise them as a sponsor on the GitHub project page as well. So that’s our model.

We’re not that unique. As an organisation, we’re also an Umbraco CMS Gold Contributing Partner, and that’s in recognition that Umbraco also has the same model. They have a free core, and then you bolt commercial products on top of that. We’re a contributing partner to that, which means we give back to that free open source by adding new features to that free platform, doing PRs, and various other things. So it’s not an uncommon model. We’re not the first to do it by any stretch of the imagination, but it’s one we believe in: if you make the core free and then allow people to buy bolt-ons, then you can sustain that core.

It’s a refreshing take on it. Like you said, it’s not the only take; you all aren’t the first folks to do this. But it does feel like a refreshing take. It feels like, so far, I’ve taken lots of shots at Duende. I’m not intending to do that. For the people who need what Duende give them, they exist, right? They exist for that reason. Then, if you want to get started with a free framework and bolt onto it, that’s where you guys come in, right?

Because at the end of the day (I need to put this gently, so that I don’t offend anybody) what you are providing isn’t magic secret sauce that only you know, right? Given enough time and enough effort, someone else could read through the OIDC spec, grab the IdentityServer4 code, figure out how that works, and then bring it up to speed. The thing that I get from using Open.IdentityServer is I don’t have to do all that, right? I don’t have to worry about that. I can be pulled, kicking and screaming I guess, into the latest and greatest of what .NET has to offer. I don’t have to spend months and years doing the work that you all have already done, right?

Yeah, that’s right. You know what? AI is a bit of a game changer here. You could argue that lots of people could spin up a fork of IdentityServer4 and start using AI to fix bugs, add new features, and all of that. But that doesn’t make sense from a planet perspective, right? Having everybody burning tokens doing the same job? That’s what we’ve done, right? So we’ve built it, we’ve been keeping it open. We see ourselves as the guardians of Open.IdentityServer, right?

It may be that at some point in the future, like in twenty years’ time, maybe Rock Solid Knowledge doesn’t exist, but we’d like to think that the source code is then given to someone else to look after, for all those other people that have contributed to it over time. We’ve had people already come to us and say they want to contribute, and they’ve actually contributed to version 3. I look at it and go, “that’s their time; they’ve given that up.” They should have exactly the same rights to that code as we do, right? So we’re just the guardians of it at the moment.

Let’s just do it once, rather than have lots of people do it many, many times over and end up burning lots of AI tokens and planet resources. Let’s just do it once, have lots of people look at it, and come up with a really good, solid solution that we’re all proud of.

And of course, the other side of the coin is the non-deterministic nature of LLMs, but also it still takes time to do. It’s not like you can type a prompt into your Claude, your ChatGPT, your Codex, whatever (I’ll do the BBC thing: other LLM providers exist as well), and then suddenly the code is magically written and pops out the other side, right? It still takes time. It just doesn’t take your time to type it, right? So it’s not like you can just go, and then IdentityServer 10 is there, right? It still requires the effort. If you’re using an LLM, you’re transplanting the effort from you to a data centre, right?

But like you said, if it’s already been fast-forwarded, it’s already there, and it already has the bug fixes, why not just go and use that, right? Because I’m a developer and I’m lazy. That gets me the solution, right? I use the joke of “I’m a developer and I’m lazy,” but the decision maker, the budget decider above me (maybe the project manager, maybe the programme manager, maybe the CTO, whatever), somebody above me has made the decision: “yes, we can swap it over, but it will take time, which means it costs money, and I want you to do it as economically as possible.” Because, like we said earlier on, if security continues to work, the user doesn’t realise, right? It’s not a feature where you can go, “oh, well, we’re now using Open.IdentityServer, look!” You can’t see it, because from the end user’s perspective they’re still logging in, they still have persistent login, they still have single sign-on. There’s no difference; there’s no new feature to point at, right?

Which, I suppose, sounds like a bad thing, but this is security, full stop, right? And maintenance, full stop. Here’s an example (Andy, you’ll learn by the end of this that I always speak in examples, right?): if you take your car and have preventative maintenance performed on it, it doesn’t perform any better. It’s still the same car, and it still works the same. It’s just guaranteed to be in as close to tip-top shape as it can be. You have a certificate and all that, which says “if it breaks, bring it back, we’ll fix it.” But it doesn’t change how the car works; it just continues to work, right? That’s what we’re talking about some of the time when we’re talking about security and all of this. I don’t know, maybe I’ve gone wildly off topic. Am I talking nonsense?

No, I think it’s like anything, right? If you buy a new car and it runs and it never breaks down, you don’t understand the experience of going out to your car in the morning, trying to start it, and it doesn’t start, and that anxiety. It’s the same with software, right? IdentityServer4 was an absolutely solid code base, and we used to sell production support contracts, where we said to people, “if it ever goes wrong, give us a call.” So when it was free, one of the things we did was sell production support contracts.

The people behind IdentityServer came to us and said, “can you do this? We’ve got people saying they love free software, but when it goes wrong, you guys are flying around the world doing conference talks.” So they came to us and said, “could you create a production support contract?” We did, and we sold some of them.

But actually, you know what? After a few years it got difficult, because the only time we talked to those customers was when we wanted the renewal fee. Eventually we had an insurance company that came to us and said, “we haven’t called you in five years. Why are we still paying for this?” And we’re like, “well, that’s the game you’re in.” I haven’t claimed on my household contents insurance for 25 years; it’s the same thing. It’s a reliable product, and I don’t think you realise the benefit of it if you haven’t had any pain, right?

I think that goes back to your analogy with the car: you do all this preventative stuff, and in some ways it might hurt your bank account, but at the same time you haven’t experienced the downtime of the car not working. IdentityServer is very similar to that. You maintain it, you keep it patched, you keep it up to date, and it rocks, and it just keeps going, and it’s a great thing to have.

One of the things we learnt from the production support situation was… we’ve actually moved now to a model where we have what we call Production Support Plus, for customers who want a specific solution for them. They don’t want to go to SaaS; they don’t want to go to Auth0 or Okta, because it costs a lot of money and the platform isn’t customised to their exact requirements. So they have a custom build of a single sign-on solution based on IdentityServer, but they don’t want their development team to have to spend time looking after it, because, going back to your point, it’s just a login screen, right? There are no new features getting added every week or every month; it just sits there. So we now provide a Production Support Plus contract where we will maintain your solution and give it at least four updates a year, and if any security issues come up, we’ll patch it immediately.

That’s the preventative thing that you were alluding to. Let’s make sure that the product that is protecting access to your applications is constantly up and running all the time, because if that’s down, nothing’s happening inside the business. So it’s gone from being that simple login screen to now something that has massive business impact. So yeah, I think it’s a good analogy with the car.

Oh, thanks. I’m always looking for analogies to try and help explain, because there could be folks listening in who’ve never done… Maybe they work entirely front end and they’ve never had to think about what auth looks like, right? Or maybe they’ve moved from project to project and they’ve never had to maintain a project for a long enough time, they don’t see the other side. Maybe they’re sitting there saying, “well, I always ask to be able to upgrade stuff, and nothing gets…” Okay, well, that’s because you’re not making a good enough case, and it’s not your fault. It’s because people see software as this nebulous, spongy thing, right?

A really, really bad analogy that has just come to me (it’s terrible, don’t listen to it, folks) is that people see security as the lock on your front door. It’s not. Security is your house, right? Because, just as you said, if the security of your app breaks, your app breaks, right? It’s not just that people can’t log in; even the people who are logged in can’t do anything, right?

So, extending that to the house: security is not the lock on the front door. It’s the front door, the walls, the windows, the foundations, the roof, everything, right? Because, to get a bit grim, if one of the walls of your house falls down, you have no security, right? It doesn’t matter how great the lock on your front door is; if one of your walls is missing, I can just walk in through the side of your house, right?

Yeah, sure. We see that all the time. Passkeys are the new mechanism for making sure that we’re using anti-phishing technology, and we can do all that in Open.IdentityServer. We can use passkeys to log in and stuff, and it all looks great. Then suddenly someone says, “what if I lose my passkey?” Well, then you have to reset. Then they say, “well, could I just get sent a code via email?” And I was like, “well, you could, but now that’s like someone breaking through your unsecured back door, or the keys under the mat.” So yeah, I think it’s super important to get security really right, and if you’re not doing it on a daily basis, it’s hard, right? It’s like anything.

That’s one of the nice things about what we offer: we’ll build people a solution and we’ll look after the solution. I’ve got a team of people who have been doing this for over ten years, and they understand all the issues, and therefore we build a solution that is solid and robust. Hopefully our customers don’t have to worry about it, because we’re there every three months doing the maintenance, checking everything’s secure and solid, that all the packages are updated, and that there are no backdoors. So yeah, it’s super important, I think.

Yeah, absolutely. Just real quick, folks: email is not a secure thing. If you’ve ever sent a postcard, it’s like that. If I send an email from me to Andy, it needs to go through a bunch of servers, and in order to get through those servers, each server has to read the entire email contents to be able to send it on to the right place. It is not secure. Stop sending things like one-time codes through email, please.

I think it goes further than that. SMS is not “secure message service,” right?

Yeah, absolutely.

It’s “short message service.” All the telcos hate the fact that all the banks have leveraged it, right? Again, we’re trying to educate a lot of our customers to say, “look, SMS is super convenient, right?” Pretty much every demographic in the UK, irrespective of age, understands SMS. Trying to get them to understand passkeys is a little bit harder. But SMS isn’t secure, right?

We had an employee that lent his phone to someone in a club to make a call. Next morning, he woke up and found that his bank account had been removed from his phone, and he’d had his whole account reset, because they’d just sent a password reset via SMS to his phone, and that was it. And their overdraft, and they cleared him out. So yeah, SMS is another terrible thing. It definitely improves security, but it’s not the panacea, by any stretch of the imagination.

Oh yeah, absolutely. This has quickly turned into “how to phish people.” But you don’t even need to go that far. You don’t need to be in a club and hand someone your phone to let them do something on it. If I know enough information about you, I can call your phone provider and have a new SIM with the same number delivered to my house.

Oh, a hundred percent.

I drop the SIM into my phone, and then suddenly your SMS one-time passwords come to my device, not yours.

Yeah, exactly. You can imagine the scenario: running into a phone shop saying, “oh, my such-and-such relative’s ill in hospital, I’ve had my phone stolen. This is the only contact. I don’t have any proof with me; everything got stolen.” As a human, you can see it; you’d probably try and help that person out. So yeah, SMS is nowhere near as secure as we probably thought it was, and the only really true stuff nowadays is passkeys, and that’s what we’re promoting with most of our customers as well.

Security is one of those things where I’m not envious of you, but security is one of those things where it feels like you’re always playing catch-up. If you’re at the coalface, writing things into the systems that everybody uses… You know how people say “never write your own cryptographic library,” because even the people with multiple PhDs who do this get it wrong? I can’t even imagine what it’s like to be in security, you know?

Yeah, sure. That’s probably a pretty good… One of the things I was going to allude to at one point was that AI is a massive thing, and our parent companies are pushing AI very hard for us to adopt it and get better throughput in terms of what we produce. We’ve made a very strong decision on Open.IdentityServer at the moment that no code that gets committed is AI-generated. But that’s not to say that we’re not using AI, because what we use AI for is checking our work, right?

We’ll build a feature against a spec, and ploughing through an RFC, trying to make sure you’ve covered every case, is a painful process, right? So we implement the RFC by hand, using traditional software engineering techniques, and then we’ll use AI to validate that what we’ve done matches the RFC. I think that’s been very useful: that second set of eyes. We’ve seen that AI is being used all the time for finding vulnerabilities, and that’s how we’re trying to use it. Not to build the actual code, but to check our work. That’s been very successful, and it allows for very quick feedback: have we missed something? Have we done something slightly wrong? Is there a hole here? So yeah, that’s been really useful.

Yeah, absolutely. You’ve answered one of the questions that I was going to come up with, which is that everybody seems to be using LLMs, AI, agentic development, whatever you want to call it. We’re not talking about vibe coding, folks. Or at least I’m not talking about vibe coding. But how does the agentic toolbox fit in the Rock Solid Knowledge Open.IdentityServer, like, panacea? But I think you’ve already touched on it: “we’ll build it ourselves, and then we’ll have” (my words, not yours) “an agent do that pair programming. Look for issues: what did we miss? What did we not get right?”

This is security code, right? So we’re not saying “review my code, don’t make mistakes.” It’s like, “here’s the RFC, here’s what we’ve put together. What have we missed? What have we misunderstood about the RFC? What have we not put in?” Maybe we’ve used strings instead of SecureStrings. Maybe we’ve used string.Equals instead of constant-time string comparison. Go learn about that; that’s really cool.

Yeah, sure. You know what, I think we’ve heavily embraced the AI side of it, but, like I said, we still want to own the security side of it, and make sure that we architect it and build it correctly, and then just use AI as the check. Because we all know that software developers hate checking people’s work. It’s not a fun job, right? It really isn’t. The fun bit is creating stuff, right? We love that. We still love creating things. But having something that’s prepared to get into the nitty-gritty of an RFC, check everything, and then check our code has been a huge help for us in being able to verify stuff. So yeah, that’s where we’re really leveraging it.

And leveraging it for building things like integration tests is super useful as well. But the actual authoring of the security code, we’re definitely doing that by hand at the moment, for sure.

Yeah, and again, that makes sense, right? Let’s take the opinions of the tech industry and put them to one side, but acknowledge that those opinions exist, right? There are lots of people out there who are saying, “a machine can’t possibly write code as well as a human.” Absolutely, we appreciate that that opinion exists, but we’re not going to talk about it. We’re going to use it as an example by saying to the community, “we’re building this security platform for you, but we’re doing it by hand and having a machine check our work.”

Well, it’s way different, but if you think about it in a sideways way, that’s what a static analyser, a dynamic analyser, and a linter are doing for you anyway, right? You’re putting the handwritten code through a process that looks for those low-hanging fruit bugs. The difference is that, from the sounds of it, you’re saying, “here’s the RFC for this particular feature, here is our architecture diagram, here is the code. What did we miss?” Well, that’s just what you would do with a human. It just takes a lot less time.

Absolutely. The nice thing about an RFC is, if you think about it, that’s a spec that’s gone through so many reviews, right? It’s had so many sets of eyes on it, making sure that the language isn’t open to interpretation and all that kind of stuff, and it’s perfect for checking our work. So that’s been super good for us in terms of helping us do that.

The other thing, really, is that in this space, security doesn’t move fast, right? So being able to add new features to bring Open.IdentityServer up to the latest specs actually isn’t that hard, right? Because new security specs aren’t dropping every five minutes. They take time, because people need to review them and look at them. So this is a great opportunity for us to build something, take our time, and build it right, because we know full well that security takes time to get adopted and evolved, and this is a perfect place for us here in this space.

That leads me on to a question that I had, and I’ll explain why. You were saying that security, especially when RFCs are involved, doesn’t tend to move at a million miles an hour, because it has to go through lots and lots of people and, like you said, the reduction of the ambiguity of human language, right? Removing the “shoulds” and making them “musts,” and making sure that everybody understands precisely how it should work. Because, just really simply, if a security system is ambiguous, it could mean that you can’t cross the street, right? Because the traffic lights have to securely communicate with the controller and all that.

With that in mind then, we’ve talked about what Open.IdentityServer is, and the migration path, which sounds like it can be done in half an hour, 20 minutes, maybe a lunch break or whatever. It seems like it’s simple and, may I say, harmless migration path: you install it; if it works, great; if it doesn’t, you remove it. We’ve talked about how it differs to all of the other things that are going on out there, and what support looks like.

But since you brought up the fact that security doesn’t move at the speed of light… To coin an old joke, there’s an npm package for it. In fact, in the time it took me to say that sentence, there are now 12 npm packages for it, right? Security doesn’t move at that speed, but it still moves. So what are we looking at for the roadmap for Open.IdentityServer? You’re saying it doesn’t stand still. I think you mentioned a whole bunch of things earlier, but what is coming next?

Yeah, sure. So we dropped version 1 in June; that was our first release, on June 2nd. Like I said, that was about getting to a point where you could safely run IdentityServer4 functionality on .NET 10 and have security fixes. Version 2 came out in August, where we added OpenTelemetry, which is very important for people to understand things like performance counters and how many requests are coming through. Maybe you’re using that to spot an attack, or just to be able to trace authentication through the process and understand what’s going wrong.

Then version 3, which is shipping in October, is more of a bigger feature release. We have two features in that: one is pushed authorisation requests, sometimes known as PAR, and the other is server-side sessions. Those are the two big features. There are a couple of other little things in there that have had contributions from other people who’ve contributed to the project, but those are the two main ones.

Pushed authorisation requests is pretty much the de facto way now of doing what we call an auth code flow. In OpenID Connect and OAuth, there are two channels we talk about: a front channel and a back channel. The front channel all goes through the browser, and anything that goes through a browser could potentially be intercepted, looked at, modified, who knows, right? Historically, if you wanted to get an access token using the auth code flow, you’d make a request through the front channel, and the URI would contain information about what you were trying to get authorisation for. That could be useful for an attacker. They could change it, or potentially see some information that they might find useful for an attack later on.

Pushed authorisation requests change that. At a very high level, it’s super simple: the client application, instead of putting that data through the front channel via the browser, sends an HTTPS request directly from the application to the identity server, not via the browser, with all that data, and it gets back a code. It’s a simple ID that represents that request. Then that ID, which means nothing except to the identity server, is used in the front channel, and that means that you hide all that sensitive stuff behind that simple ID mechanism. There are other advantages in terms of the size of URLs, which can sometimes be limiting, and various other things.

So that’s one feature we’ve put in. It’s pretty important: the Microsoft client library for OpenID Connect, which everybody would probably be using, will default to PAR, assuming that your identity server supports that type of request. So that was super important for us. We had a lot of customers saying that’s one of the things that was maybe preventing them from switching: they needed PAR support.

The second one, really, is server-side sessions. We talk about single sign-on in the sense that you log in once, then you can visit lots of applications, you don’t have to see the login box again, and you just move around those applications. At some point maybe you go idle for a certain period of time, in which case, what should happen? The application could log you out, but really what we want is some notion that when you’ve stopped using the session that you’ve created with the single sign-on solution, all applications are automatically logged out, through what we call back-channel logout.

Again, that was another big feature that people said they needed. It was part of Duende, and they needed that support in order to be compliant. The pen testers would say, “well, if my session times out here, I want all my applications to be logged out, because it is single sign-on.” So that feature has dropped in October. Those are the two things.

Going forward, we’ve got things like dynamic client registration being added, which allows clients to get added without actually going into an admin portal. There are a couple of mechanisms to do that: there’s dynamic client registration, and there’s also the ability to use client ID metadata documents, where rather than your client ID, you’re using a URI to point to the definition of your client.

But probably the biggest one for Q1 2027 is something called DPoP. With OAuth you get an access token, and that token, going back to your analogy with the front door, is like a key, right? Anybody that has your front door key can use it to open the door. So when an access token gets granted to someone, if somehow someone can steal that access token, someone else could use it. DPoP is an extension to the protocol, Demonstrating Proof of Possession, where effectively you need not just the access token, but you need to be able to prove, through the use of public/private key pairs, that you do actually have the rights to that access token.

That’s a very important thing when we start talking about FAPI compliance. FAPI used to stand for Financial API, but it covers any type of API that’s protecting very sensitive data, whether it’s banking or medical stuff. There’s a series of OAuth profiles that say, “you need to use OAuth like this in order to be compliant,” and DPoP is probably one of the big ones that we need to look at implementing in 2027, in order to satisfy that area of the market.

That’s really interesting to me, because, not knowing much about it, it sounds very much like… Yeah, you can rotate your keys very, very often, but it’s a trade-off. Let’s say your JWT, right?When you regenerate it, you have to re-authenticate. Maybe you’ve got a 15-minute re-authentication, which means that at some point in the next 15 minutes, whilst the user is working, you need to get a fresh token. Great. But then that token is still there in the browser context, still being passed around, and anyone can grab it at any time. Before what you’re talking about here, if I can grab that token whilst it’s being transferred over the wire, I can then just do stuff on that person’s behalf.

But with what you’re talking about, like you said, I need to prove that I should have access to that token. We’re not talking about a JWT, presumably, but I have to prove that I should have access to it, rather than just that I do have access to it. So I’m reading it as (and please correct me if I’m wrong) MFA, but for the token bearer.

Yeah, well, you could argue it’s like you can use the front door key, but the front door key has got a fingerprint sensor in it that checks your biometrics, or something, before it enables the key to be used. I don’t know; I guess there are lots of analogies we could use. But, over time we keep moving the goalposts in terms of what good, solid security is, and people find ways around it, and we’re just constantly improving that.

For lots of people, DPoP is probably one step too far. It’s a lot of extra complexity. But for lots of people who are securing very secure bits of data, it’s essential, right? You can’t afford for an attacker to… They can spend a sufficient amount of resource to get a token, because they know the reward is pretty high, right? So we do need that support in order for Open.IdentityServer to work in those spaces where the security has to be the top gold standard in terms of how we can protect those APIs going forward.

Absolutely, yeah. As with everything in secure coding and application security, the answer is always “it depends.” Because, like you said, you can chase after putting DPoP into your app, but if all your app is doing (air quotes) is allowing someone to log in and say, I don’t know, that they’ve drunk a coffee today, and then log back out again, maybe that data isn’t worth protecting with DPoP. Because that data should just be a username, a token, and that they had coffee today, right?

I couldn’t think of a really good example, but if your app is a low-stakes app, then maybe it’s not required, and you should really think about “do we want to be the coffee-drinking app that advertises that we are fully DPoP compliant?” Because maybe you don’t need to be. But if you are a bank, or if you are a hospital… I would presume there would be different things in place for government, but if you are a government, you probably want to aim for at least that, and have that as your base level, right?

Yeah, absolutely. That’s what we’ve got. We’ve got customers at the moment who are very happy with basic auth code, right? Not even PAR. Then we’ve got other customers who want to use PAR; that’s a very trivial thing. Like I said, we’ll also have other customers who go, “no, absolutely, we need DPoP. The stuff we’re protecting is that important.” So yeah, it’s horses for courses. Like I said, we are getting there, and I expect that in Q1 2027 we’ll have a DPoP implementation, so that we can increase the ecosystem that is happy to accept Open.IdentityServer in 2027.

So we’ve talked a little bit about what’s coming down the pipe. How do folks get involved then? You said earlier on that it’s free forever. Does that mean it’s free open source? If it is, can I just jump onto GitHub, maybe raise an issue and say, “I’ve seen this thing, I’d like to take this, is that okay? Can we have a conversation?” Then raise a pull request?

What about documentation? Is that on the Rock Solid Knowledge website, or is there a website just for Open.IdentityServer? If someone’s listening in and saying “I desperately want to use this,” is it just a case of dotnet add package, I’m guessing, Open.IdentityServer, and then figuring it out from there? I know we said that earlier on, but as we’re wrapping up, I just want to reiterate to people how easy or difficult it is to get started.

Yeah, okay. In terms of contributing, like I said, you can contribute financially by buying the products; that’s great. If you want to contribute code, there are a few things you can do. You could create an issue on the GitHub page which says “I need this feature,” and that’s absolutely fine; we’re not necessarily expecting you to build it. We’re also happy when people come along and say, “I can see you’ve got these features in your backlog that someone’s created (or maybe I’ve created it, who knows), and I’d like to get involved. I’d like to build the code for that.” We’re very happy with that. We’ll manage the pull requests, because, again, we see ourselves as the guardians of it, so my team will be doing those pull requests. As long as people follow the rules, where we’ve said that we don’t want AI-generated code here, then we’re very happy for people to contribute.

Like I said, we’ve had customers who did their own private fork who are now unpicking some of their changes and contributing them back, and we’ve been working really well with them to make that happen. So that’s been super good from that perspective, and that’s really what we want. To make this project really successful: the more developers we have on it, hopefully the more successful it will be, right? So that’s the plan there.

Documentation: all the documentation is in GitHub. You can host it yourself if you want to, but it is hosted on docs.identityserver.com. In terms of getting started, if you’ve already got existing Duende projects or an IdentityServer4 project, then we’ve got videos and guides on how to do the migration. If you’re starting from scratch, again, we’ve got some quick start guides, but we’ve also got some .NET templates. We’ve got a .NET template where you can do your dotnet new, and that will build you a pretty much ready-to-go solution that targets SQL Server or Postgres, and also comes with a UI for you to manage the configuration.

That’s a commercial part, the AdminUI bit. It will work and allow you to create a couple of applications, but after that you would have to pay for it. It would at least allow you to get started and have some UX, so you can play around with it without having to dive into the database and manually add rows and that stuff.

So hopefully we’ve got some quite easy ways to start: either through migrating from IdentityServer4 or Duende, using the quick starts, or even just using a .NET template to get something up and running really quickly. Then you can start pointing your application at it, and make sure that you’re happy that you integrate well with OpenID Connect.

Awesome. Well, that’s set me up with a challenge, I guess: to take one of my old apps that is .NET Framework, which I won’t be able to run on this machine because I’m on a Mac, and…

Well, that’s a nice choice to start with, so that’s good. You’re on a Mac, excellent.

Yeah. So I’m going to have to set myself the challenge of: can I upgrade this app, which is just a throwaway playground app, to a modern-ish .NET? Then, can I replace IdentityServer with Open.IdentityServer, and see how easy that is to do? There are a lot of people I know who don’t want to play around with swapping out their security thing, because “it works, and I don’t know how it works, but it works, and I tell it what to do,” and that is a perfectly fine place to live.

But being able to swap over from one provider to another, with virtually no downtime in that migration path, just makes it easier for everybody, because then everybody can continue doing what they do best. My forte is not security. My forte is not identity or OIDC or any of the things we’ve talked about. But if I know that the library I’m using is maybe not as correctly placed as, say, a different one, and I can migrate over and it takes me 20 minutes, half an hour, maybe an hour tops, well, I’m happy.

Because that’s an hour, versus “oh my goodness, we’re going to have to have downtime, we have to have migration scripts, we need to move from this thing to that thing, then we need to get people in. What happens if it all goes wrong? How do we roll back? How do we guarantee data integrity?” We don’t have to do any of that, because I could just do dotnet add package and off we go.

Absolutely, and that’s what we’re aiming to do here. We’re not trying to create a drama for people; we want people to be able to move with confidence and with little upset. Because, again, it goes back to what you said: the login screen is still the login screen. The important thing is that you go to bed at night knowing that the thing that’s securing your environment is fully patched, it’s got no vulnerabilities in it, and it’s protecting the rest of your ecosystem. That’s the thing that you need to take away from it.

If we can make sure that it’s not a big drama, and you don’t have to think “well, I’m just going to ignore it, because it’s just too much effort,” then that’s a good thing, right? So that’s what we’re giving. If you’re on IdentityServer4 today, migrating to Open.IdentityServer is a no-brainer, because it’s literally a fully patched, supported version, and you don’t need to worry about it, effectively.

Excellent, excellent. Well, Andy, we are very rapidly running out of time. Playing a little bit of inside baseball: we’ve only got four minutes left of our recording session, so I’d better wrap things up pretty quickly.

Wow. Sure.

But it has been a pleasure speaking with you today, Andy. Like I said, it’s filled me with this idea of “do I dust off one of these old repos, try to migrate it, and see what happens?” Because it’ll be fun to see what happens, right? I’ve got a free afternoon coming up. Let’s see what I can do.

Yeah, and if you want to invite me back, we can talk about your experience; that’ll be even better. But yeah, I’m confident that you’ll be able to do it, and it’ll be a great experience.

Excellent, excellent. Well, in these final few minutes then, what about if people are listening in and going, “these Rock Solid Knowledge chaps (I use ‘chaps’ as a gender-neutral term), these Rock Solid Knowledge chaps sound pretty awesome. How do I find out more about them?” And I wonder if Andy’s about on socials, maybe on LinkedIn or something. Maybe I can send him a connection request and learn a little bit more about what’s going on. Is that something that you’re open to? Is that something that you do?

Yeah, absolutely. Please feel free to reach out. If you’ve got any questions on Open.IdentityServer, just email support@identityserver.com. I’m available on LinkedIn. I’ve got a reasonably unique name in the UK. It’s not so unique in the US, but Andy Clymer is reasonably unique in terms of finding me, so finding me on LinkedIn is pretty straightforward. Or my email address is andy@rocksolidknowledge.com. By all means, email me if you’ve got any questions on anything you’ve heard today, or have any concerns. I’m very happy to have an open and transparent conversation.

All of that will be in the show notes, folks. So if you’re listening in on your podcatcher, on YouTube, wherever you’re hearing this… or indeed, hey, if you’re reading the transcript, you’re already way ahead of me. But if you’re listening in, you can go to the show notes website, and there’ll be a full transcript there. If you put /index.md on the end of the URL for the transcript, it pumps it out in Markdown, so you can give it to an agent and say “summarise this” or “find the bit where Andy said…”, and it will do it all for you. That’s there too.

But yeah, all of those links will be in the show notes. I’ll put a link to all of the things that we’ve talked about: the docs website, the videos that show you how to get set up and running, if I can find them. I’ll put Andy’s LinkedIn in there as well. So yeah, cool. Awesome. Andy, it’s been a pleasure. Thank you very much.

No, thank you, Jamie. It’s been great. Thank you very much.