What is OAuth 2.0?

Okay, you might not know what OAuth 2.0 is, but you will have surely used it for several websites. Nowadays, many websites allow you to log in with your username and password for Facebook, Twitter, or Google accounts. Go to your favorite website, for example, the www.stackoverflow.com login page. There is a login button that says you can sign in with your Google account, for example. When you click on the Google button, it takes you to Google's login page along with some of the permissions mentioned. Here you provide your Google username and password and click on the Allow button to grant permissions to your favorite site. Then, Google redirects you to Stack Overflow and you are logged in with appropriate permissions in Stack Overflow. This is merely the end user experience for OAuth 2.0 and OpenID Connect.

OAuth 2.0 can be best described as a series of specification-turned-authorization frameworks. RFC 6749 defines OAuth as follows:

"The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf."

OAuth 2.0 handles authorization on the web, in native mobile applications, and all headless server applications (these are nothing more than microservice instances in our context). You must be wondering why we are discussing authorization first instead of authentication. The reason is that OAuth 2.0 is a delegated authorization framework. This means, to complete the authorization flow, it relies on an authentication mechanism.

Now let's see some terminology associated with it.

OAuth 2.0 roles describe the involved parties in the authorization process:

• Resource: The entity that is getting protected from unintended access and usage. This is nothing more than a microservice in our case.
• Resource owner: Resource owner is a person or entity who owns the specified resource. When a person owns a resource, he or she is an end user.
• Client: Client is the term used to refer to all kinds of client applications. This refers to any application trying to access the protected resource. In a microservices' context, the applications involved are single page applications, web user interface clients, and native mobile applications, or even a microservice that is trying to access another microservice downstream.
• Authorization server: This is the server that hosts the secure token service and issues tokens to the client after successfully authenticating the resource owner and obtaining permissions from the resource owner or on their behalf.

You may have noticed that OAuth does differentiate between end users and applications used by an end user. This is a bit odd but makes perfect sense since it is also generally viewed as saying, I am authorizing this app to perform these actions on my behalf.

The following diagram depicts how these roles interact with each other in the general flow of authorization in the OAuth framework:



In step 6, illustrated in the preceding diagram, the client passes the authorization grant to the authorization server. This step is not as simple as it looks. Authorization grants are of different types. The grant types represent four, different possible use cases for getting access tokens in OAuth 2.0. If you choose the wrong grant type, you might be compromising security:

• Authorization code: This is the typical OAuth grant used by server-side web applications, the one you would use in your ASP.NET apps.
• Implicit: Authenticating with a server returns an access token to the browser, which can then be used to access resources. This is useful for single page applications where communication cannot be private.
• Resource owner password credentials: This requires the user to directly enter their username and password in the application. It is useful when you are developing a first-party application to authenticate with your own servers. For example, a mobile app might use a resource owner grant to authenticate with your own servers.
• Client credentials: This is typically used when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.