If you want to sign in to Medium using an email address instead of a social media account, you are met with the following screen:

You'll then be sent an email that looks something like this...

Recently I’ve been looking into blockchain for decentralised identity and authentication. I’m not sure how I feel about blockchain for authentication yet, but I can definitely see the befits of having some sort of decentralised identity system. It turns out there are a lot of identity blockchain projects out there already, some even have released products (and yes, others already gone bust).

I like learning by doing, and from my initial research I’ve found Civic to be one of the more popular platforms. So, what I’m going to do is dig into the technical aspects of the Civic platform and, in a separate article, integrate with it using ASP.NET Core.

To get started with civic, I’m going to use it as an authentication method in an ASP.NET Core application. This will use the ASP.NET Core MVC Visual Studio template, with no authentication. Authentication is going to be triggered manually using a login button in the sites header.

You can find the completed proof of concept on GitHub.

Recently, as part of messing around with an identity provider, I was given the following private/public key pair and told to sign a JSON Web Token (JWT) with them using ES256:

Private: c711e5080f2b58260fe19741a7913e8301c1128ec8e80b8009406e5047e6e1ef
Public: 04e33993f0210a4973a94c26667007d1b56fe886e8b3c2afdd66aa9e4937478ad20acfbdc666e3cec3510ce85d40365fc2045e5adb7e675198cf57c6638efa1bdb

Okay, sounds simple enough. 5 days and a lot of swearing later, I finally got it working. Now I’m going to write it down so that I don’t have to go through it again.

In .NET Core, to sign a JWT using an Elliptic Curve Digital Signature Algorithm (ECDSA) we need to get ourselves an instance of ECDsaSecurityKey. The constructor for this takes in an instance of ECDsa, which in turn we have to pass in an instance of ECParameters if we want to load in our own key and not have it generate one for us. So, let’s make a start!

In my previous article, we looked at how to get an access token and use it to access a protected resource, in Kotlin. Now we’re going to take a look at the other side of the story: how to validate an access token (in this case a structured JWT) before allowing access to the protected resource.

For token verification we’re going to:

1. Get available public keys from a JWKS endpoint
2. Parse the public key used to sign the receive JWT
3. Verify the access token signature, issuer, and audience. This will also verify that the token hasn’t expired (the exp claim), that it was issued in the past (the iat claim), and that the token is allowed to be used (the nbf claim)

We’ll then use this logic to protect an API endpoint running on Ktor.