Examining OAuth

Introduction

These days practically every website you use involves creating an account. This generally involves creating a username and a password. Managing all of these passwords can be tricky, and using the same one for everything is a dangerous practice. Typically most sites provide another option and that is to sign in using credentials from another service you are signed into such as Google or Facebook. This will generally take you to a confirmation screen that is hosted by the service you are getting the credentials from. Once you confirm you’d like your credentials from the selected account shared with site you are trying to log into you will be lead back to the original site logged in. There are some steps that happen behind the scenes before these credentials are shared and we will go over them in the next section. The practice of implementing this is called OAuth.

What is Oauth?

Oauth stands for Open Authorization and like previously stated is a method of granting applications access to their information from a 3rd party application. It is important to note that passwords and sensitive information like saved payment methods are not shared. There are several different ways OAuth is implemented and each of these are called an OAuth Flow. During this article we will cover three of them: Authorization Code Flow, Implicit Flow, and Client Credentials Flow. Before we delve into this though there are some key terms we should cover first that we will be using to describe the OAuth process. Here They are:

• Resource — is the sought after protected resource like a profile picture or an email address.
• Resource Owner — The person who has access to the resource (the user) and can grant access to said resource.
• Resource Server — The server that is holding/hosting the protected resource (such as google drive).
• The Client — The application which needs access to the protected resource.
• Authorization Server — The server that issues access/auth tokens to the client.

Another important term that doesn’t necessarily have to be used within OAuth is JWT and this stands for JSON Web Token. This is a standard that defines a compact way of communicating between parties using a JSON object. These are digitally signed using either a private secret or a public/private key. Now that we have the terms covered lets crack into the various OAuth Flows:

Authorization Code Flow (safest)

1. The Resource Owner has logged onto The Client service and has requested The Client access a Resource.
2. The Client sends a request to the Authorization Server to receive the Resource.
3. The Authorization Server sends a request to the Resource Owner to verify The Client should get access.
4. The Resource Owner verifies with the Authorization Server that The Client should get access to the Resource.
5. The Authorization Server having verified that the Resource Owner wishes The Client to have access to the Resource grants The Client a short lived Auth Token which will be used for future communication with the Authorization Server on the Resource Owners behalf.
6. The Client uses its new Auth Token to send another request to the Authorization Server to receive an Access Token.
7. The Authorization Server checks the Auth Token and grants The Client an Access Token that can be matched to a particular Resource on the Resource Server.
8. The Client uses its new Access Token to make a request to the Resource Server for the Resource
9. The Resource Server checks the Access Token and responds to The Client with the Resource

Implicit Flow (Steps 1–4 are the same as the Authorization Code Flow)

1. The Resource Owner has logged onto The Client service and has requested The Client access a Resource.
2. The Client sends a request to the Authorization Server to receive the Resource.
3. The Authorization Server sends a request to the Resource Owner to verify The Client should get access.
4. The Resource Owner verifies with the Authorization Server that The Client should get access to the Resource.
5. The Authorization Server having verified that the Resource Owner wishes The Client to have access to the Resource sends the Access Token directly to The Client
6. The Client uses its new Access Token to request the Resource from the Resource Server
7. The Resource Server checks the Access Token and responds to The Client with the Resource

Drawback — Anyone with the Access Token can get the resource from the Resource Server and this flow does not guard the access token with an auth token. Due to this the Access Token for the Implicit workflow is short lived.

Note — There is an Oauth Flow called the Abstract Flow which is steps 2–7 of this.

Client Credentials Flow (Authorization Between Microservices)

Within this workflow there are some new terms.

• Microservice 1 — The service requesting the data.
• Microservice 2 — The service holding the data.
• Auth Server — Typically contained within Microservice 2, provides authorization for particular resources within Microservice 2.

The steps for this flow are as follows:

1. Microservice 1 makes a call to the Auth Server and provides a particular key which identifies it as a particular known microservice.
2. The Auth Server verifies it knows of this particular microservice and grants it an Access Token for a particular resource within Microservice 2.
3. Microservice 1 uses its new Access Token to make a call to Microservice 2 for the desired resource.
4. Microservice 2 verifies the Access Token is valid for the desired resource and responds with the desired resource.

Conclusion

While Oauth was originally conceived for granting authorization for particular resources it is now used as a method for authentication as well. It does this by piggybacking off of the authentication process of a 3rd party such as Google or Facebook. The current version of Oauth is called OAuth 2.0 and address a security flaw in which users were vulnerable to session fixation attacks. The convenience of a more central location of resources as well as ease of use means Oauth probably isnt going anywhere anytime soon.