In that strange period between Christmas and New Years, I finally had a chance to finish off some long-running dev tasks for IdentityManager2. This means that IdentityManager2 now targets ASP.NET Core 3.1, has dropped the beta suffix, and is now contains less legacy code from v1.

It would be wrong not to thank ChaosEngine who’s pull requests and gentle nudging helped make this release happen.

If you have an ASP.NET MVC application in production that uses IdentityServer, you may soon find yourself in its codebase due to the upcoming SameSite cookie changes spearheaded by Google.

While you’re in there messing with the code, why don’t you give your old application a freshen up and update your OpenID Connect usage to take advantage of some of the features of the newer OWIN libraries and the latest security recommendations of authorization code plus PKCE?

I wrote one of these articles last year, talking about what I’d been up to since 2016 and my plans for 2019. I found writing that blog post quite therapeutic, and over the past year, I often caught myself coming back to it (and not just for the pictures).

So, here’s another nostalgic blog post, for a year that felt both too short and too long.

What Happened in 2019

To start, I’ll pat myself on the back. In 2019 I...

Sometimes you need to use an algorithm that your goto libraries do not support. Whether it’s because your platform’s cryptography libraries don’t implement it yet or because a particular client library doesn’t support it, sometimes you need to go off piece.

In this article, we’re going to look at how to do that when using the Microsoft.IdentityModel JWT libraries, using ES256K as our custom signing algorithm. Example code will both generate and verify a JWT signature.

I’ve been using the Java library “Nimbus JOSE + JWT” to create JWTs recently. It has been pretty useful for playing around with uncommon JOSE algorithms such as ES256K and EdDSA. Considering that these are not supported out-of-the-box in .NET yet, being able to use another stack to generate test data has been invaluable.

So, this is one of those blog posts where I write down how to use the library for signature generation and validation for future Scott to reference once he inevitably forgets.

While playing around with IdentityServer4 and mTLS client authentication, I was recommended mkcert for generating trusted development certificates. I found this tool to be super simple to use and it saved me from having to use OpenSSL or the PowerShell replacement for MakeCert (New-SelfSignedCertificate).

So, I thought I would document how to use mkcert on Windows and how to use it for some ASP.NET Core development tasks such as client authentication and pfx generation.

If you are looking to get an understanding of the various approaches to user authentication, how they rank up, and what libraries to use to implement it in ASP.NET Core, then check out my new Pluralsight course: “ASP.NET Authentication – The Big Picture”.

I have designed this course so that you can either watch it end to end or pick the parts that matter to you; with the aim to give you both a pragmatic overview of modern authentication, along with a practitioner’s recommendation of useful libraries with which to implement them.

As of version 5.5, Microsoft’s IdentityModel library now supports the signing of JSON Web Tokens using the RSASSA-PSS (Probabilistic Signature Scheme) digital signature algorithm. This is great news if you’re looking to start building .NET Core systems that implement OpenID’s Financial-grade API and Open Banking, where PS256 should be used for signing.

You can find the full list of support for various .NET targets on GitHub, but the exciting thing is that PS256, PS384, and PS512 are now supported on .NET Core.

Sign in with Apple was recently released as part of Apple’s WWDC 2019 conference. They’ve essentially weighed into the identity provider space with the username and password being handled by Apple ID and 2FA handled by your registered Apple devices.

Sign In with Apple gives us a new alternative to other social login providers such as Google and Facebook. However, unlike those services, it seems to be more aimed at identity and authentication, rather than access to services such as Google calendar.

Password Authenticated Key Exchange (PAKE) is one of those odd protocols that sounds like a great idea, but one that no one seems to be using. Even then, it seems no one can agree upon a good implementation. Secure Remote Password (SRP) is the most common implementation, found in use by Apple and 1Password; however, it is far from perfect.

I’m underqualified to explain any of those sweeping statements, so I’m going to leave it to cryptographer Matthew Green, who has two excellent articles on both PAKE and SRP. I highly recommend reading at least the first one before implementing PAKE in your application.