OAuth 2.0, OpenID Connect and Identity Server

OAuth 2.0, OpenID Connect and Identity Server

When it comes to authentication and authorization, the most used standard is OAuth 2.0 with OpenID Connect (OIDC).
Few weeks ago I discussed Resource owner password and Implicit flows focusing mainly on implementations with Identity Server. There is a lot of confusion revolving around OAuth 2.0 and OIDC, what they are, how they differ and even what Identity Server is and what is it used for. Today I will give more insights on what is OAuth 2.0 and OIDC are and how Identity Server relates to them.

1. What is OAuth 2.0
2. What is OpenID Connect
3. What is Identity Server 4

1. What is OAuth 2.0

OAuth 2.0 is an authorization protocol enabling applications to have a limited access to protected resources. The authorization is handled in the Identity provider (Idp) who is in charge of delivering an access token to the client apppication after having authenticated the resource owner (usually the user).

Why do we need it?

Let’s take an example.

I have an application where you are a user. When you log in, I want to get your profile picture from Facebook to display it on my application.
The straight forward approach would be for my application to ask your Facebook username and password and to log into your Facebook.
But this will cause multiple problems:

  1. you would be giving your credentials to a my application,
  2. you wouldn’t know what I will be doing with it,
  3. I will have full access to your account, there is no way for you to restrict the access to only the parts you would want to share,
  4. it would be hard to revoke access, the only way would be to change your password.

This is where OAuth 2.0 comes into picture. Facebook implements OAuth 2.0 which allows my application to request from you a piece of your information on Facebook.
To do that, you are redirected to the official Facebook login on Facebook site, hence your credentials would only be handled by Facebook whom you trust, and then Facebook would issue me an access token allowing me to access only the resources you have granted my applicaction to access.

The access token delivery providing limited access to a protected resource (like Facebook) is what OAuth 2.0 was designed for.

OAuth 2.0 makes it possible via different flows; Authorization code, Implicit, Client credentials and Resource owner password flows:

  • Authorization code is used for clients who can keep a secret between themselves and the idp like hosted frontend.
  • Implicit flow is used for pure frontend clients like SPA who can’t keep a secret.
  • Client credentials is used when the client needs to authenticate as itself, for example when your own application needs access to your own protected resource.
  • Resource owner password is used when the client is trusted. Be very cautious with this flow as the user credentials will need to be given to the client for the client to pass it to the idp.

OAuth 2.0 protocol also defines how clients are registered and how exchanges occur on which HTTP endpoints.

But what it does not define is how to identify the user requesting the access token.
A common practice is to return a second token signed by the identity provider, deserializable by the recipient containing the identity of the user. But because this was not defined by the protocol, every company providing external login capabilities had to create their own way.

Then came OIDC.

2. What is OpenID Connect

Initially every company was writing their own way of providing the identity of the user, either by including an identifier within the access token returned or by providing an extra token as part of the OAuth 2.0 flow.
From there OpenID Connect was created as a simple authentication protocol layer on top of OAuth 2.0 with the goal of providing a unified way of authenticating users.

OIDC standardized the delivery of the id_token within the existing flows of OAuth 2.0.

OIDC standardizes the way to identify the user by providing an id_token together with the OAuth access_token within the current flows available. For example in an implicit flow it will be provided at the authorization endpoint together with the access token while for an authorization code flow, it will be provided by the token endpoint.

The important part to understand is that the access_token provided by OAuth 2.0 is for the resource to be accessed while the id_token is for the client application to identify the user authenticated.

Now that we know what is OAuth 2.0 and OIDC, we need an implemenation.

3. What is Identity Server 4

Now that we know what is OAuth 2.0 and OpenID Connect, we need a framework which allows us to implement the protocols.

Identity Server 4 is a framework implementing OAuth 2.0 and OIDC in the .NET ecosystem and most importantly in ASP .NET Core.

In previous blog post I have covered two flow implementations:

But all the flows are actually supported and there are examples backing up the flows on the github of identity server
https://github.com/identityserver.
The project is totally open sourced and very well maintained and is OpenID certified.

An important point to note is that while it is responsible for the implementation of the protocols, Identity server does not manage users. The responsability to store users, manage their information together with credentials is left to the developers. This allows us to choose which database we want to use and how we want to store our user.
There are already package created to support common implementation of membership systems like ASP .NET Core Identity.

With Identity Server 4, we will get OAuth 2.0 and OIDC, coupled with ASP .NET Core Identity for storing and managing users, we will have the full picture for authentication, authorization and management of users.

Conclusion

Today we saw what was OAuth 2.0 and OIDC. We also deciphered some of the concepts around authorization versus authentication and lastly we saw Identity Server 4, a .NET implementation of it. Hope this post was helpful! See you next time!

Comments

Post a Comment

Popular posts from this blog

Microsoft Orleans logs warnings and errors

Microsoft Orleans logs warnings and errors Microsoft Orleans is a framework which helps building distributed system by implementing the actor model together with the concept of virtual actors, taking care of availability and concurrency. If you are unfamiliar with Microsoft Orleans, you can look at my previous blog post explaining the benefits of Microsoft Orleans . Even though Orleans promises to abstract the distributed system problems, there are instances where errors arise without us being able to understand what is going on. Lucky us, the logs are well documented… but only for those who can decrypt them. Today I will go through some of the errors and warnings which can be seen from silo and client so that you too can undestand what is going on. Enjoy! The code used to produce those errors can be found on my GitHub https://github.com/Kimserey/orleans-cluster-consul . 1. Client logs Logs on client appears with address {ip}:0 . 1.1. Can’t find implementation of interface An un...
Keep reading

A complete SignalR with ASP Net Core example with WSS, Authentication, Nginx

SignalR with ASP Net Core SignalR is a framework from ASP NET Core allowing us to establish a two way communication between client and server. This two way communication allows the client to send messages to the server but more importantly allows the server to push messages to the client. SignalR makes use of Websocket when available else it falls back to SSE or pulling. Today we will focus on how to setup SignalR to work with WSS, Websocket secure and how we can authenticate the user requesting to connect to our SignalR hub via Webscoket. Getting started with SignalR SSL encryption for Websocket Secure WSS Websocket Authentication with Identity Server 4 SignalR behind Nginx 1. Getting started with SignalR The Hubs are the main components of SignalR. It is an abstraction of a two way communication available for both client and server. Public functions from the hub can be called from the server code and can be called from the client. The frontend NPM package @aspnet/signalr ...
Keep reading

SDK-Style project and project.assets.json

SDK-Style project and project.assets.json Last week I encountered an issue with MSBuild while trying to run it from command line. The issue did not appear when using VisualStudio right click + build but only appeared when using msbuild.exe CLI directly with a clean project. Assets file 'C:\[...]\obj\project.assets.json' not found. Run a NuGet package restore to generate this file. When I first saw the error, few questions came to my mind which I will share today in 3 points: Overview of project.assets.json Slim SDK-Style project Mixing SDK-Style project and old projects Special shoutout to @enricosada who provided me with all the answers regarding the SDK-Style project. 1. Overview of project.assets.json project.assets.json lists all the dependencies of the project. It is created in the /obj folder when using dotnet restore or dotnet build as it implicitly calls restore before build, or msbuid.exe /t:restore with msbuild CLI. To simulate dotnet build (re...
Keep reading