Explaining Oauth

Born around 2007, and now with two major "rebirths", Oauth (pronounced "Oh" - "Aw"- "Th") has grown up to be a classy teenager with a huge (100%) following on Gmail, Facebook, Instagram, Twitter and almost all major social platforms. Its following on all these platforms, being in the billions, would make even Cristiano Ronaldo jealous!

How did Oauth do it? What is Oauth?

It has achieved such fame thanks to its stylish capability for authorizing users and applications to access secure information.

Have you wondered what happens when you click and open any app on your phone? How are you securely allowed to access your data, and how is it that others cannot access your data, and moreover when you install other complementary apps (eg. you install Strava on top of Fitbit), how is that you can securely delegate access to these other complementary apps?

Introduce Oauth …. imagine a world without Oauth …. no-one will be able to access their trusted email, social media, or other apps on their mobile devices. You can thank Oauth for its quiet, unassuming work behind the scenes to keep your information secure. Though it is not the only standard, and it is definitely not without its flaws, it must be recognized that it is one of the heavy workhorses of the free internet that we enjoy today.

How to describe Oauth and what it does? I wanted to describe its basics so that even one’s grandmother could grasp the concept. Therefore, I propose to use three separate approaches to describe this sophisticated yet simple method of authorizing users. This is an exercise in explaining technical concepts simply!

1. The first approach is using declarative statements
2. The second method is to use questions
3. The third method is to provide an analogy or metaphor

Each of these methods will delve a little deeper into the concept, so you need not read any further unless you want more details. At the end of this article, I hope to leave you with a little better appreciation of the humble Oauth standard.

Statement 1: You want to access information

At its heart, Oauth is about authorizing access to information. Information is power, and so you need access to the information at your fingertips.

“I need to access my bank account information”

Statement 2: You need to ensure information is secured

Whilst you need to access your information, it is also important that your information is not accessed by unauthorized third parties.

“I don’t want my bank account to be accessed by unauthorized parties”

Statement 3: You need to be able to delegate access to information

Even though you want to protect your information from access by unauthorized parties, the converse is also true. You need to be able to delegate access to this information to those whom you explicitly authorize.

“I want to delegate access to my bank account to my spouse or partner, or other third party”

Statement 4: You need to ensure that methods and protocols are also secure

In addition to the information being secure, the methods and protocols you use to deal with intermediaries, third parties, brokers, and other such groups that handle this information must also be secure. This recognizes that there are people out there that wish to cause harm by stealing your information, and will go to any lengths to sabotage you.

“I want my bank to correspond with me in secure, reliable ways. Conversely, I do not want my bank to send confidential details of my bank account via unsecured means”

If you understood nothing about Oauth except the four statements above, then I believe you have grasped the basics. Of course, even though I have used the example of banks and bank accounts, Oauth operates at the level of access to information over the internet network, not any physical access to information. All the above, including accessing information, authorizing this access, delegating access, and securing the communication, occur within the blink of an eye and you are reading your email or updating your task list or managing your bank account with confidence.

Perhaps we can conduct a thought experiment …. suppose you or I were asked to design a method where anyone could access information securely over the internet as per the four statements above. How would we design this scheme? How would we ensure that everyone could access their information securely, knowing there are millions of criminals prowling around the internet ready to steal everything we own? Luckily, we do not have to design this scheme from scratch, as it has already been designed and is called Oauth 2.0.

But here are some salient points about how you may go about designing such a scheme, and therefore I move on to my second method of describing Oauth.

Question 1 – Identification – Who are you?

Before you can access information over the internet, the first step is to make sure you identify who is accessing the information. This is called identification. There must be a mechanism to identify the end user (you and me), as well as to identify intermediaries that access the information on my (and your) behalf. In the internet world, these intermediaries are usually called apps.

Think about intermediaries in this way: your email app on your phone is an intermediary “agent” you are trusting to process your email information securely. Similarly, the bank app on your phone is another intermediary you are trusting to marshal your banking information.

As simple as it sounds, there is (yet) no universally accepted, fool-proof method to identify every single person (end-user) on this planet. Ten fingerprints, iris scans, facial recognition, genetic codes and such have been devised by various countries and organizations. However, the humble username and password are still the de facto method to identify someone on the internet today, usually combined with something that the person possesses, such as a mobile phone or some other device. In terms of identifying intermediary apps, the method still used is to “register” this intermediary and issue this intermediary with (you guessed it) a unique name and password, or in Oauth it is also called a client ID and secret. In Oauth, intermediaries are called “clients” (intermediary is my own term).

Question 2 – Authorization Rules – What information are you allowed (or denied) to access?

Once identified, you need a mechanism whereby the end-user or intermediary can be authorized to access or modify various pieces of information, and conversely denied accessing or modifying other information. You must provide a means of specifying, for example:

• End-user or intermediary 1 can access and modify information A, B, and C, but not D, or E
• End-user or intermediary 2 can access and modify information A, B, C, D, and E
• End-user or intermediary 3 can only access information A, B, C, D, and E but not modify any of it

In Oauth, the information sources are usually APIs which can be called to retrieve (for example) emails, task lists and bank accounts from your app.

Who specifies these rules? It is the resource owner (owner of the information). I, as the owner, can decide who is allowed to see and act upon my information.

When are these rules established? They are established by the resource owner at the start even before any information requests are received, and the resource owner can change these rules at any time.

Makes sense? Kinda simple!

Question 3 – Authorization Request – Can I access this information?

Once these rules have been specified as above, then the authorization scheme must allow end-users or intermediaries to request access to information. That is, the rules may say that a user can access information A, B, and C (as above for end-user 1) however right now, the user only needs access to information A. In this scenario, the end user should only request access to information A, and subsequently, they will be granted access to information A, assuming the resource owner had authorized such access. If a user requests access to information that they are not authorized for, then such access must be denied. In the example above, if end-user 1 requested access to information D or E, then this must be denied. In Oauth, the list of information you are requesting access for is called “scope”.

Question 4 – Authorization Key – Can you give me a key to access the information?

Once it has been determined that I am allowed to access information, then I must be given a key to access such information. This key must only work to “open” the information that I requested in the authorization request above, not any more, not any less. This key must allow repeat use, but must also be temporary, otherwise, it will be subject to theft by unauthorized parties wanting to access my information. For this reason also, the best practice is to request access right before you need to use itc, rather than requesting access for all information upfront in case the user may invoke it.

In Oauth, this key is called the access “token”. Note that if such a token is intercepted and stolen by a malicious third party, then it is likely that you will suffer unauthorized access to your information. Therefore, it is imperative to protect this token, and in Oauth, such tokens are almost always sent only to “confidential” clients. Think of confidential clients as known organizations operating at specific known URLs that also secure incoming and outgoing communications with strong encryption. For example, Gmail web app would be a confidential client because it is a registered organisation with a known web URL, and moreover all communications coming into Gmail web app and going out of it are encrypted. Oauth does also support sending tokens to public clients, and this is called the implicit flow, to be touched upon a little later, however as mentioned, this is highly risky. More on public and confidential clients later.

Now that I have described the Oauth in two different ways, and if you still need more, then below I provide a simile or metaphor to describe it further. For those wanting such lower-level details, you can read further below. The analogy I will use belongs to another similar problem – the Power of Attorney.

Metaphor

The owner of an estate or assets may grant me the power of their entire estate composed of multiple properties and assets. The power that I am granted may only be to access the asset (let’s call this read-only), or it may also allow me to access the asset and execute actions upon it such as selling it (let’s call this read-write). Whatever powers I am granted by the owner, however, when I need to execute that power such as access that asset or act upon the asset, I must explicitly request and be granted this right at the required point. As mentioned above, I should only request authority right before I need to use it, not sooner. If I need to sell an asset on behalf of the resource owner, I should request such authority right before the sale. Otherwise, the authority could be stolen, and combined with identity theft, someone else could be selling and profiting from the sale.

It goes without saying that as the owner of the assets, I can access and act upon any of my assets at any point without having to seek authorization from anyone else. The least I need to do is prove my identity as the owner. And unlike Power of Attorney, this Oauth authorization needs to happen at lightspeed over the internet, not over faxed pieces of paper with signatures!

The diagrams further below further describe the basics of this analogy. Here below, I describe it in words.

Say that I am the owner of four types of titles, these being property titles, share titles, vehicle titles and heirloom titles (eg. jewellery). I keep these titles in the safe deposit at my bank and specify rules around who can access each title. I request the bank to allow my spouse to access all 4 titles, my son to access the property titles, my daughter to access the share and heirloom titles and my accountant to access the property and share titles. I expect that the bank will honor these rules and keep my titles safe from unauthorized access. I also expect the bank to explicitly check with me when any one of these parties requests access to the titles they are entitled to access.

In the table below, I describe the comparisons between my analogy and Oauth.

Now let's see how this works in six steps. The below is describing only one possible flow, also known as the "Authorization Code Grant flow". This flow is typically used by web server-based apps that need to access APIs to retrieve user information.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

At this point you may have a multitude of questions:

• Why are two steps required – authorization grant and then token grant? Why can’t the token be issued in one step?
• When did the client get registered?
• What if the authorization grant or token that is issued is stolen?
• What happens when the token expires?

At this point it is worth noting that although the basics have been described with this simple analogy, OAuth has additional features and security considerations, and some of these are touched upon briefly here.

• Different flows or grant types – what I have described is the basic authorization code grant flow. Oauth specifies more flows, to cater to the variety of different types of scenarios and types of clients, and another flow is the implicit flow, whereby the token is issued as a result of the authorization request itself. In my analogy, this would be equivalent to the bank issuing a key directly as a result of the original authorization request, rather than issuing an authorization letter first. Note that the different grant types exist because Oauth caters to many different scenarios such as a confidential client wishing to access an API (standalone), a public client wishing to access an API, an end user wishing to access a browser-based application, an end-user accessing a web application which in turn accesses an API, so on.

• Client types – clients can be confidential, such as a secure server or public. The owner must treat public clients with a greater level of mistrust. Examples of public clients are native apps installed on mobile devices and web-browser-based applications. Authorization grants (in my analogy the authorization letter) are often sent to the client via the user agent, and therefore can be intercepted (in my analogy, the letter can be intercepted by a malicious third-party). Because of this, a new extension to the Oauth protocol was invented called PKCE (proof key for code exchange). In this extension, another random code which it sends with the authorization request, which the authorization server also decodes and stores. Later, when the client requests or tries to exchange the authorization grant for the token, the client again sends the same random code, which the authorization uses to verify that the authorization code has not ben intercepted. Even in the case that the authorization code was intercepted by a malicious third-party, this third-party would not be able to reproduce the random code, and therefore will be denied.

• Refresh tokens – every access token has an expiry date and time. These refresh tokens are to acquire another access token, in case the original access token expires

• Scope – a client can specify a scope (as a list) of items that it wishes to access, the authorization server maintains a list of items that the client is authorized to access. If the client requests a scope that is different from the authorized scope, then the token issued only includes the restricted scope that the client is authorized to access.

• Claims – a lot more information can be stored against each token, and these are called "claims". These claims can be used by the by applications and resource servers to decide what information to present. In multi-tenant applications where there the application has multiple users accessing it, then the claim can contain information about the user, thus telling the application that only information associated with that user must be returned, and not information belonging to another user. This would be akin to someone else receiving your emails or bank account information, and that is definitely undesired!

With this, I hope to have shone some light upon this Internet standard that works so hard behind the scenes. Only the very basics have been covered, however it is important to understand these basics before delving deeper into the more sophisticated aspects. It is still evolving, with schemes such as PKCE which has been introduced more recently, and some of the older and more insecure aspects being dropped, such as password grant flow. As it evolves, the basics have remained quite solid. Feedback welcome!