What is OAuth? How does this authentication work?

What Is OAuth?

OAuth is an open-standard authorization protocol that can be added to applications to offer users secure designated access to their platform. For instance, with this protocol, you can tell Facebook to allow ESPN.com access to your social media posts and updates without necessarily releasing your login credentials. This sort of access helps to reduce risk in a big way. If ESPN.com suffers a data breach, the information you have with Facebook will be protected.

OAuth does not operate by sharing passwords with other platforms. Instead, it sends authorization tokens to them. This token is used to prove the authenticity of the identity. It's a crucial strategy to employ between customers and service providers. In simple terms, this concept is an authentication protocol that allows platforms and service providers to interact without giving out their passwords.

‍

OAuth Examples

A common example of this protocol is related to most android devices. When you purchase an android smartphone, it requires you to log in to your email account to access most of the features on that phone.

When you have logged in your email into the phone, you will need the information to access other applications or login websites. The principles of OAuth allow users to share their email login credentials with the platform instantly. You don't need to input your password but the website will instantly be provided with authentication to offer you designated access.

There are numerous other use cases and examples that highlight the concept of this protocol. As long as you can share your credentials for information across platforms without having to input your password repeatedly.

A good example of this protocol in principle is when you are redirected to another website and sent a message that says; "hey, do you wish to log in to our website with the credentials from another website?" Let's call the website that is requesting a user's access as the receiver while the platform where you are currently logged in will be referred to as sender. When you try to log into the receiver or receiving website, it will demand to know if you are the same user who is logged in on the sender or sending website.

Facebook is one of the most common examples of platforms that use this protocol. When you're using an app on Facebook, it will demand access to your profile information and pictures. In this scenario, Facebook is the sender with your login data and pictures. The app is the receiver, and as the user, you intend to use the services of the receiving platform. By clicking on allow, you give the receiver access to your pictures while OAuth facilitates the entire process.

Some of your smart home devices, such as television, security system, toaster, and so on, require login access to be able to control all of them from your browser or mobile device. These devices operate on what is referred to as OAuth confidential authorization. They'll hold on to your login credentials securely. That way, you don't have to input your login credentials at different website terminals.

‍

OAuth History  

OAuth isn’t the work of a single person. Many big tech giants like Google, Twitter, and many more joined hands to formulate this globally recognized authorization standard. It was first offered to the public in 2010 as RFC 5849. Soon after its launch, it became highly famous in the API community. With time and evolving requirements, the community demanded updates in it.

Hence, multiple versions came into being. RFC 6749 or OAuth 2.0 was the second version of OAuth and came into being in 2012. This version received heavy criticism in the beginning but later became very famous. Presently, companies like Netflix, Facebook, PayPal, Amazon, and many more are using it.

‍

OAuth Components

• OAuth Tokens

Just like the conventional bank tokens that were used to allow customers to be a part of the queue and fetch money from their accounts, digital tokens are for granting permission to use/access the system resources too. See the 2 categorizations of OAuth tokens that one can use:

1. ‍Type #1: Access Tokens

Think of them as the temporary permission to reach a resource that has a set expiry duration too.

They have timed resources that API users use to find out the API call resource. They are created and last only for a few minutes or hours and can be accessed by both private as well as public types of clients. OAuth tokens are capable of fixing issues related to internet scalability. It’s not easy for an end-user to revoke the OAuth token as they are short-lived by default.

2. ‍Type #2: Refer Tokens

Instead of short-life bank queue tokens, this type matches more will transport passes that give you access to the resource more than once – within a particular duration (longer than the previous type).

These tokens have longer life as compared to access tokens and remain active even for years. The key purpose of referring to a token is to obtain a new token. They only work with private clients backed with enough authentication facilities.

Unlike access-type tokens, they are easy to revoke. When someone tries to revoke the application-access procedure, the refresh token gets damaged and leads to a data leak. The process tries to fetch a new token forcefully and thereby impacting the API resources negatively.

There is no clarity about the format of both these tokens. As per the present information, OAuth tokens are accessible in the format of your choice. However, API developers prefer using JSON Web Token or JWT over any other token type as it allows you digitally sign the token, which is great from a security point of view.

You can retrieve both types of tokens using the respective endpoints (Widely-used ones are: Authorize & Token) that can connect with the auth-server. Each end-point has a distinct use case. For instance, the endpoint concerning the end-user-related permissions and identity checks is Authorize.

‍

• OAuth Scopes

This array of data is shared with the app/user when it seeks permission. The app must go through authorization before receiving it. Scopes exist in a bunch and represent the client-generated permission for requests.

Generated by the app developers, scopes exist from the very beginning when app coding/designing begins and are useful for authorization policy decoupling. 

Scopes are the primary OAuth elements and indicate that the permission has to be at the front and very much clear. No doubts are entertained at this process. One can obtain the OAuth Scopes used by an API by referring to API docs.

‍

• OAuth Actors

1. The resource-owner can be an end-user, company, or enterprise. It has the right to reach out to a resource server, and it might own a whole or some data saved there. For instance, everyone, who has a social media account, is the owner of the respective SM profile. The password, handle name, username, and any other details related to the said profile are the properties of the resource-owner.
2. The resource-server is the API that holds the data that the respective website/application wants to obtain. For instance, FB API holding the login details that the FB Messenger app will use to complete the login will be called a server.
3. The client is the app trying to access your login or other data so that it can allow you to enter its system. It could be private or public. If someone wishes to enter into his/her Facebook account, it’s the client.

‍

• OAuth Flows

1. ‍Implicit flow

In this kind, communication is happening via browser only, and no backend server is in charge of authorization grants. SPA falls under this category. It works well only with browser-based public clients and rejects refresh tokens; only access-type of tokens are used by the implicit flow. As it’s entirely browser-based, it’s more prone to cyber threats.

2. ‍Authorization Code Flow

Often known as 3 Legged, this type of flow is the gold standard of OAuth flow and uses both front as well as back channel. A client app utilizes the front channel for accessing authorization code grants, while the back one plays its part in exchanging grants.

3. ‍Client Credential Flow

Again, here client means the app/browser that is interacting with the server. As the flow is related to credential exchange, security is an utmost priority at this stage.

The flow type is ideal for server-to-server communication. This flow includes only the back channel process to reach the access-token utilizing the client information. It helps in keeping information secure as client details are backed by symmetric and asymmetric keys.

4. ‍Resource-Owner Password Flow

This is a legacy flow sharing great similarities with a direct authentication process. as it lacks security, it’s not at all recommended. No refer token support is offered, and it considers that Public clients and Resource Owners are coming from the same source.

5. ‍Assertion Flow

An updated flow, this type is very much similar to client-credential flow and came into being to support the federation idea. It permits the Authorization server to accept and take care of the 3rd party authorization grants. It’s mostly used by organizations heavily using SAML or related technologies.

6. ‍Device Flow

Device flow isn’t web-based but device-specific. It allows the client apps to use back channel flow to survey the auth approval. Both access, as well as refresh tokens are handled by it.

‍

How Does OAuth Work?

The reality is that OAuth was designed to focus on authorization and not authentication. Authorization involves seeking permission to perform certain actions. However, authentication is concerned with proving that you are the person who has the required access to the information secured within the profile. OAuth doesn't ask the user to authenticate, instead, it authorizes access to other apps and resources.

A good way to review the working mechanism of this protocol is by looking at the analogy of a valet key. The valet key is designed to give a valet access to drive your car, but will not necessarily allow them to open the trunk. The OAuth token is designed to be the valet key to your smart device. As a user, you are in control of the information that will be shared across platforms. You can hand a valet key to each receiver. However, they will never have full access to the full key or confidential data that are hidden within the profile.

There 3 main parties that are involved in any OAuth transaction; the user, the sender, and the receiver. The 3 parties may be referred to as OAuth Love Triangle. We'll use a few simple steps to illustrate how an OAuth offers authentication protection for users on multiple platforms.

• Step 1: The User Shows Intent
• Step 2: The Receiver Gets Permission. A secret will be sent along with the permissions which will be used to prevent forgery and verify the source of the permission request.
• Step 3: The User Is Redirected to the Service Provider or Sender
• Step 4: The User Gives Permission
• Step 5: The Receiver Obtains an Access Token
• Step 6: The Receiver Accesses the Protected Resource

SAML vs. OAuth

Many people are quick to refer to the similarities between SAML and OAuth, but most concepts couldn't be more different. SAML, also known as Security Assertion Markup Language, is an alternative authentication standard that is many organization uses to support single-sign-on features. SAML is a feature that enables organizations to monitor those who are in charge of corporate resources.

There are many differences between SAML and OAuth. SAML adopts XML to send messages while OAuth sends messages with the use of JSON technology. OAuth is designed for a simpler mobile experience, while SAML is designed to offer you better security. The last difference between SAML and OAuth is a major one. OAuth relies majorly on API. Due to this reason, many mobile apps, modern-day websites, game consoles, and the Internet of Things rely on this protocol. Generally, OAuth offers a better experience for users. To offer authentication to users, SAML drops a cookie session in the user's browser that lets the person access certain web pages. This idea is great for short-lived access but doesn't do much when you have to log into that network repeatedly.

‍

Article Comparison - How OAuth Differs From SAML And OpenID

OpenID vs OAuth

In simple terms, OpenID is used for authentication while OAuth serves the purpose of authorization.

OpenID supports federated authentication, which means that it supports third-party apps to support and authenticate users when trying to use accounts you already have. However, OAuth was designed to make sure that you don't have to input your login credentials on third-party apps.

Both protocols can be used to accomplish similar tasks but that doesn't mean they should be used interchangeably. OpenID provides an identity assertion while OAuth is more generic. When a client uses OAuth, a server issues an access token to a third party, the token is used to access a protected resource, and the source validates the token. Notice, that at no point is the identity of the owner of the token verified.

‍

‍

OAuth 1.0 vs. OAuth 2.0

OAuth 2.0 is designed to be a complete improvement on the workings of OAuth 1.0. The two similar frameworks are not compatible. If you create a new app or website today, make sure that it relies on OAuth 2.0. Most modern-day websites have switched to OAuth 2.0 because OAuth 1.0 has depreciated.

The latest version of OAuth, version 2.0, is easier and faster to implement on applications and websites. OAuth 1.0 was designed to rely on cryptographic requirements. It also did not support more than three flows or even scale.

OAuth 2.0 is designed with six flows that support different applications and requirements. This authentication protocol allows signed secrets over HTTPS. OAuth tokens do not need to be encrypted when they are sent from one endpoint to another. That's because they are encrypted in transit.

Is OAuth Safe?

It’s important to assess the extent to which OAuth can actually help you out. While TLS encryption warrants considerable security, the onus is on the implementation quality. Anyone using OAuth must make sure that no coding is happening without TLS encryption. It’s possible to code that will help in automatic TLS encryption enforcement during authentication.    

If TLS encryption isn’t applied everywhere and there are loopholes in security binding, possibilities are there that an ill-intended website can phish the login info and use them against the user who is trying to access the website. We have already witnessed this happening in 2017 when over a million Google accounts were phished this way only. Hence, OAuth is not completely safe. It demands due diligence at the time of implementation.

‍

How OAuth Protects APIs

It's possible to secure API with API connect. OAuth is a special authorization protocol that makes third-party websites and apps accessible without logging the user's credentials or personal information.

OAuth User Scenario

People who use API Connect along with this protocol have several methods they use to protect their API. These are some of the available options:

• Creating an OAuth Provider API. The provider API will contain OAuth tokens for both endpoints of an OAuth flow.
• Protecting an API with OAuth security definition. When you add this protocol's security definition to your app or website, you add settings that allow you to control API operations through the OAuth authorization standard.
• OAuth Metadata URL and Authentication URL. You can set OAuth metadata URL or authentication URL that will be used to obtain user-specific content from a website. It will access it from a remote server and add it to the access token or as a part of the payload that contains the security token.

OAuth Responses

During the OAuth 2.0 process, the API connect produces various responses to requests.

Troubleshooting OAuth

If you have any problems with this protocol, you can troubleshoot by yourself. Navigate to the Developer Portal and forums on Youtube, Github, and DeveloperWorks.