OpenID Connect is the go to protocol for modern authentication, especially when using Single Page Applications, or client-side applications in general. A library I often recommend to clients is oidc-client, a plain JavaScript library that is part of the IdentityModel OSS project. This handles all of the necessary protocol interactions with an OpenID Connect Provider, including token validation (which strangely some libraries neglect), and is a certified OpenID Connect Relying Party conforming to the implicit RP and config RP profiles.

In this article, we are going to walk through a basic authentication scenario using the Angular CLI and the oidc-client library, during which we will authenticate a user, and then use an access token to access an OAuth protected API. This will use the implicit flow, where all tokens pass via the browser (something to always remember when dealing with code executing on the client, because the application cannot be trusted with features such as long lived tokens, refresh tokens or client secrets)...

oidc-provider is an OpenID Connect provider for node.js, providing us with a secure authentication mechanism for our applications, and protection for our APIs. In this article, we’re going to walk through setting up oidc-provider and interacting with it using a couple of different ways.

Why oidc-provider?

It’s a Certified OpenID Provider Library and it’s a framework, unlike some providers which you can only mount and then modify select areas. Whilst this can be good for ensuring expected behaviour (you may be less likely to create security flaws or break functionality), it can be infuriating if you need custom logic or even grant types. The library is certified for all 5 OpenID Provider conformance profiles.

Project Setup

If, like me, you are a complete newbie to node.js and express.js, then the below commands are how we setup a new app...

Knowing why we don’t use past methodologies can be just as useful as knowing why we use current ones. In this article, we are going to look at past methods for delegating access to an API (the problem that OAuth is the current solution for) and why we shouldn’t use them anymore. Examples in this article are based on systems I’ve seen in the wild or discussed on StackOverflow.

Scenario

For a user to delegate access (or authorize, give permission) to a mail service to send emails on the user’s behalf. Only send permission must be allowed.

We’re going to use the OAuth terminology of...

SharePoint is a popular document collaboration platform from Microsoft, capable of running multiple web applications which in turn consist of multiple web sites. SharePoint also comes with of the box support with other Microsoft products such as Office 365 and Active Directory.

But what if you want to use SharePoint with non-Active Directory accounts? Or have SSO across all of your applications, even on mobile devices? Even Azure AD B2C struggles with this, due to it’s lack of support for SAML 1.1 tokens. This is where traditional identity providers start to struggle and IdentityServer steps in.

I recently made the move to Cloudflare and have been talking to anyone who will listen about how great it is, both for simplicity and nerdy security features. Yes, even after the media sensation that was #CloudBleed.

One of the things I wanted to do once I moved to Cloudflare was ensure that I had TLS across the entire pipeline. Whilst Cloudflare will ensure you have TLS between the browser and their servers, but they’re a bit more permissive when it comes to TLS between their servers and your origin server (in my case Azure App Service). You’ll see these kinds of images floating around explaining this...