It seems as though cyber security is perpetually in our newsfeed for one reason or another (and it’s never a good thing). What often isn’t included in these stories is the fun stuff, the theory and frameworks for implementing good security practices.

What is OpenID Connect?

OpenID Connect is an identity layer that allows applications to verify the identity of an end user. It sits above OAuth protocol and can be setup to incorporate an authentication server (which can seriously benefit an application over the course of its lifetime.

The simplest way to describe OpenID Connect is to give examples. When you first join a product like Spotify, you’re given the option to create an account or sign in with Facebook/Google. There is a good chance that the application is using OpenID Connect.

Authentication vs Authorisation vs Auditing

First things first, when we talk about application security, there are three main concepts to be aware of. This is often referred to as a AAA approach to security.

Authentication is proving that someone is who they say they are. At times we may have multiple factors to prove that you are who you say you are (this is multi-factor authentication). Authorisation on the other hand is that based on who you are, this is what you’re allowed to do. This is where we look at permission levels. Auditing is the ability to determine who did what.

When we look at OpenID Connect, we are talking about the authentication process.

If you would like to learn about

The Benefits of OpenID Connect

Straight off the bat, there is a benefit to not having your own user accounts. By leveraging someone else’s, you not only improve the user experience (who enjoys managing 100 different accounts and passwords?) but the authentication is done by a third party.

We also mentioned above that you can create your own authentication server. Changing the identity provider (or the authentication process in general) can be tricky. A dedicated server for authentication that can be updated separately is extremely powerful. It enables you to move closer to that microservice architecture, with a key concern separated from the rest of the application.

A few key definitions we want to raise before going through the diagram above:

• Back channel refers to server to server communication. This is more secure than front channel communication as it can’t be intercepted by a browser redirect or dodgy extension.
• Front channel refers to server to browser communication.
• ID Token is a reference to user identification. Most commonly it is the UID in the database but not always.
• Authorisation code is a token that grants permission from the service provider. It is generated at runtime (think of it as an API key).
• Scope is what the service provider allows you to access.

Keep in mind this is a very general overview to the OpenID Connect process. For more detailed documentation, head here.

Firstly, the client (let’s use our Spotify example from earlier) will send the user to the authentication server with a few query parameters. This might include the return URL, perhaps a tag if they’re using a different third party integration. The scope of information that Spotify wants to collect will also be sent here. Sometimes this is shown to the user depending on the trustworthiness of the client.

If the client isn’t trusted, there may be a requirement for the user to consent to the scope of information collected. Once logged in, we give them a code and the user is redirected back to whatever the callback URL was. From the users perspective, that’s where the journey ends.

On the back channel, the server will exchange that code for an access token. Then the client may also use a resource server to request information like the users email or date of birth.

That’s an overview of the OpenID Connect process. For more on application security, check out our learning space and subscribe for updates.

Our Way of Working delves into the bread and butter of our software development process, which you can check out here.