Azure Key Vault is a great way to store your IdentityServer4 signing keys; it is secure, versioned, and gives you access to robust access control mechanisms. However, I keep seeing many Azure Key Vault integrations that miss many of its features by storing the private key as a secret and then downloading the private key on application startup.

In this article, I’m going to walk through an IdentityServer4 proof of concept in which the private keys never leave Azure Key Vault.

No private keys were downloaded in the making of this article.

Last week Google released an open-source FIDO2 authenticator called OpenSK, implemented in Rust.

OpenSK is not too dissimilar to the Solo Key, but unlike Solo, it is not yet suitable for everyday usage. It is not FIDO certified, and at the time of writing, it uses Rust implementations of the required cryptographic algorithms (e.g. ECDSA), as opposed to using available hardware-accelerated cryptography. For now, OpenSK is for research purposes only.

In this article, I’m going to talk through my creation of a security key using OpenSK (I am a Windows user, and this is all new to me). I’m also going to see how well the current implementation works with a FIDO conformant relying party (registration and authentication) such as FIDO2 for ASP.NET Core.

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.