Access control via OpenID Connect (OIDC)

This blog post gets hands-on about access control, including everything from the difference between authentication and authorization, how this works in a couple of CNCF projects, and how to set it all up.

Specifically, we’ll talk about the basics of OpenID Connect (OIDC). In short OIDC makes it super easy to integrate your application with external services. Users can grant your application access to their data in a secure way. You’ve probably seen this in action: you get a prompt to log in to a new site with you Google account, and boom, you’re in.

Business value

One of the benefits of developing an application in a world that is already full of great services is that you don’t need to reinvent the wheel for everything. If you want to create a new frontend for a contacts list, there’s already a lot of services where users already stores their contacts. So why not just piggyback on those services and then you don’t need to worry about how to create that backend.

Alright now that you have created your super awesome frontend, how should we get the contacts from the external service?

• Should we ask the user to input the contact information to its friends again to our site?
  • Kind of defeats the purpose, we didn’t want to implement the backend for this.
• Should our app ask for the credentials to the other site, so that we can log in as the user?
  • This also gives us full access to the users account and we need to make sure to store the credentials very safe. Maybe not ideal from a security perspective.
• Should we use a standardized way of requesting the users data from that site, so that the user can give explicit consent and allow us to fetch only the users contacts?
  • Now we’re talking!

I guess the answer is quite obvious.

With OIDC we can do exactly this. In a standardized way, a user can grant access to some data in one service to a completely separate service. And since it’s standardized, we can use any backing identity provider that supports OIDC. So by implementing this one protocol we can use multiple external services and allow users to log in via a service that they already trust. And if we have our own internal login service, we can utilize this standard so we’re able to develop and update the login service at its own speed, separate to the application itself.

About

To understand OIDC, we first need to iron out some often confusing concepts, authentication and authorization and get a good understanding of OAuth 2.0, since OIDC is just a small extension to OAuth.

Authentication and authorization

These two terms are often confused or used interchangeably, however as concepts and functions they are different and need to be understood as such.

If we start with authentication, this is simply the process of determining who a user is. This can be done in a lot of ways, like asking the user to provide something that only the user knows (like a password). Or maybe by something they have (like a One-Time Password – OTP – generated by their phone).

Next up is authorization, what are a user allowed to do. This could be that a developer are only allowed to deploy an application to staging, while an operator are allowed to promote it to production.

So once we know who a user is by authenticating them, we can determine what they are authorized to do. This sequence of events is important, we cannot decide what a user can do if we cannot be sure who the user is.

OAuth

OAuth is a protocol that allows the user to delegate (authorize) a service to do certain actions on its behalf on other services. A great example of this is some thing most of you have seen. A button that says “Login with Google” or the consent screen “Allow app X to your use your contacts”.

This is all part of the OAuth Flow.

Lets have a look at a OAtuh Authorization Code flow.