Integrating with Civic SIP using ASP.NET Core

05 February 2018 Blockchain Identity

This article pairs with another article: “Technical Review of Civic’s Secure Identity Platform”. The verdict is that the current implementation has some very strange design decisions that do not add anything to the overall security. Instead, a standardised approach should have been taken using OAuth or OpenID Connect, as opposed to the current self-rolled authentication protocol.


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.

Read more

JWT Signing using ECDSA in .NET Core

02 February 2018 C#

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.

.NET Core

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!

Read more

JSON Web Token Verification in Ktor using Kotlin and Java-JWT

20 November 2017 Kotlin


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.

Read more

Experimenting with Kotlin and OAuth

15 November 2017 Kotlin


I’ve recently been picking up Kotlin and, since I work with authentication and authorization protocols on a daily basis, I used a basic OAuth scenario as my learning activity and thought I'd share my journey.

The scenario was to issue an OAuth request, parse the results, and then access a protected resource using the resulting token. This is not using any of the browser based grant types, instead just back end communication using the token endpoint and the client credentials grant type.

I’m not a Java developer, so this use of Kotlin has also been my first experience with that entire eco system. As a result...

Read more

Silent Refresh - Refreshing Access Tokens when using the Implicit Flow

01 November 2017 OpenID Connect

When using the implicit authentication flow refresh tokens cannot be requested or used, since the client application cannot be explicitly or securely authenticated and therefore cannot be trusted with such a sensitive token. This also applies to any flow on a public client incapable of keeping a secret or making secure back channel requests. If a refresh token intended for a such a client was stolen, the thief could use it to request access tokens for that user, without their knowledge or consent.

When using a client application running in the browser, which the OpenID Connect implicit flow was designed for, we expect the user to be present at the client application. They might be currently in a different tab or even on a different application than the browser, but the session is still active. This means that if their access token expires, they should still be around to authorize another to be issued. We’re not expecting the client application to be performing any sort of background tasks or long-running processing.

But what if, for instance, the user was filling out a form in the application and their access token expired?

Read more