OAuth stands for Open Authorization. It is a process through which an application or website can use authorization tokens to prove an identity between consumers and service providers. In simple words, OAuth allows you to approve one application interacting with another on your behalf without giving away your password. For example, you can use an application without signup or without creating an account on that application by just using OAuth which further generates an authorization token for services like Google and Facebook to give controlled access to your profile information from the services like Google, Facebook, etc.

How OAuth 2.0 Overcomes the Problems and Limitations in Data Authentication

Before the advent of OAuth, a typical web application or website was used to share credentials with a third party. This creates several problems and limitations:

• Third-party applications are required to store the resource owner’s credentials for future use, typically a password in clear text.
• Servers are required to support password authentication, despite the security weaknesses inherent in passwords.
• Third-party applications gain overly broad access to the resource owner’s protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.
• Resource owners cannot revoke access to an individual third party without revoking access to all third parties and must do so by changing the third party’s password.
• Compromise of any third-party application results in the compromise of the end-user’s password and all the data protected by that password.

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token — a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

Pros and Cons of Various Data Authentication Standards

There are several options available in parallel to OAuth 2.0 for authentication and authorization on the web. Here are some of the most popular options with their pros and cons:

1. OpenID Connect
OpenID Connect is a protocol built on top of OAuth 2.0 that adds an authentication layer to the authorization flow. It allows the user to authenticate with an identity provider (IdP) and receive an ID token that the client can use to verify the user’s identity.

Pros:

1. One can offload the authentication of a user to an OpenID provider such as Yahoo! or Google. Using this method, you can take advantage of the provider’s large membership and security systems to log your users into your site.
2. The straight OpenID approach is more lightweight than the hybrid auth implementation.
3. One will not need to store user login credentials in your own database systems; rather, you simply map the OpenID user on the provider site with whatever information your application or site stores about that user.

Cons:

1. OpenID is simply an authentication service for verifying a user account state, not an authorization system like OAuth, which allows an application or service to perform actions on the user’s behalf once authorized. What this means is that a simple OpenID integration will not be able to make signed requests to the provider site to get, set, or delete a user’s social information.
2. The support for OpenID extensions—such as Simple Registration, Attribute Exchange, and PAPE—is inconsistent from provider to provider. Some providers support all popular extensions, while others support none.

2. SAML (Security Assertion Markup Language)
SAML is an XML-based protocol used for exchanging authentication and authorization data between parties. It allows the user to authenticate with an identity provider and receive a SAML assertion that the client can use to verify the user’s identity.

Pros:

1. SAML is a free source and a standardized application, and it is compatible with any system independent of implantation.
2. Security is the utmost requirement of all enterprises, and fortunately, SAML is one of the most protected applications for SSO. It delivers a single point of authorization and authentication to secure identity providers. And the service ensures that the user login information never leaves the security system. To provide additional security: SAML uses the PKI (Public Key infrastructure) to protect confidential information from breach.
3. The identity provider has centralized access that provides an easy way to access and deactivate the user account. SAML SSO allows you to create the user id, update it and remove the users without much hassle.
4. The application is super easy to use, and switching the app is also super easy. SAML allows users to log in to hundreds of applications by entering their credentials. The SSO feature of SAML delivers a seamless business experience and helps in saving time.
5. The greatest thing about the SAML is that it can be transported by simple transport protocols such as SMTP (simple mail transfer protocol) and HTTP (Hypertext transfer protocols).
6. SAML is known for the ease it has provided to large enterprises. SAML offers the best user experience. It allows users to seamlessly access multiple applications that help business staff efficiently and effectively.
7. SAML abstracts the security framework from platform architecture and vendor implementation. With SAML you can ‘reuse’ logging in with the username and password multiple times across multiple services.

Cons:

1. It can be more complex to implement than OAuth 2.0, and it requires the use of an IdP.
2. SAML uses XML as the markup language. Over the years, it has been proved that XML is not the best format for security constructs.
3. Web applications work wonderfully, but mobile apps lack several things. Like mobile apps, do not advertise the metadata, so you must use file-sharing or manual configuration.

3. JWT (JSON Web Token)
JWT is a compact, URL-safe means of representing claims to be transferred between two parties. It can be used for authentication and authorization by including user information in the token.

Pros:

1. JWTs (JSON Web Token) can transfer user details. This eliminates the need to query the database or authentication server for that information on every request.
2. JWTs can be verified efficiently and quickly because they do not require a database lookup.
3. JWTs are only stored on the client side—the server generates a JWT and sends it to the client. The client then sends a JWT with each request. This saves database storage space.
4. JWTs provide strong security guarantees. They are digitally signed and cannot be modified by clients or attackers.

Cons:

1. JWTs cannot be revoked without significant additional engineering work because there are no database calls when validating.
2. Immediate revocation of JWT requires implementing a JWT blacklist, which can be time-consuming.
3. If the signing key is compromised, an attacker can use it to construct a valid JWT. This makes it possible to impersonate the identity of a user.

4. OAuth 1.0
It is an older version of the OAuth protocol still supported by some APIs (Application Programming Interfaces). It provides a mechanism for authentication and authorization like OAuth 2.0 but with some differences in the flow and security mechanisms.

Pros:
Transport-independent. Security is not delegated to HTTPS/TLS.

1. Digital signatures are used to prove the integrity and authenticity of a message. Digital signatures can ensure that a certain message was sent from a specific source and that the message and signature were not tampered with in any way.
2. Messages are each individually cryptographically signed

Cons:

1. OAuth 1.0 was designed to rely on cryptographic requirements.
2. OAuth 1.0 only handled web workflows.
3. The client-side implementations can be especially complex.
4. OAuth 1.0 is deprecated.

How OAuth Works Behind the Scenes?

OAuth defines four roles:

1. Resource Owner: – An entity capable of granting access to a protected resource. When a resource owner is a person, it is referred to as an end-user.
2. Resource Server: The server hosting the protected resources can accept and respond to protected resource requests using access tokens.
3. Client: – An application making protected resource requests on behalf of the resource owner and with its authorization. The term “client” does not imply implementation characteristics (e.g., whether the application executes on a server, desktop, or other devices).
4. Authorization Server: – The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

The abstract OAuth 2.0 flow illustrated in the above figure describes the interaction between the four roles and includes the following steps:

1. The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown) or indirectly via the authorization server as an intermediary.
2. The client receives an authorization grant, which is a credential representing the resource owner’s authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.
3. The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
4. The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.
5. The client requests the protected resource from the resource server and authenticates by presenting the access token.
6. The resource server validates the access token, and if valid, serves the request.

The preferred method for the client to obtain an authorization grant from the resource owner (depicted in steps (1) and (2)) is to use the authorization server as an intermediary.

Types of Grant Flow

There are five types of grant flow defined and described to perform authorizations.

1. Authorization Code Grant
This is the most used grant type. In this type of grant, the client redirects the user to the authorization server having the following parameters in the query string.

• response_type: which contains the value code
• client_id: which contains the client identifier
• redirect_uri : which contains the client redirect URI (Uniform Resource Identifiers)
• scope: which contains a space-delimited list of scopes
• state: which contains a random string

After successful authentication, the user will be redirected to the Consent screen where he needs to provide consent to abc.com to access the account detail. Authorization code is generated by the authorization server and sent back to the client with redirect Uri.

The client will now send a POST request to the authorization server with the following parameters:

• grant_type: which contains the value of authorization cod
• client_id: which contains the client identifier
• client_secret: which contains the client secret
• redirect_uri: which contains the same redirect URI the user redirected back
• code: which contains the authorization code from the query string

The access token is never exposed to a web browser in the entire flow.

2. Implicit Grant
This simplified OAuth flow was recommended for the client-side applications where the access token was returned immediately without an extra authorization code exchange step. This flow is entirely prohibited by some of the servers due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.

The client will redirect the user to the authorization server with the following parameters in the query string:

• response_type: which contains the value code
• client_id: which contains the client identifier
• redirect_uri : which contains the client redirect URI
• scope: which contains a space-delimited list of scopes
• state: which contains a random string

3. Resource Owner Credentials Grant
This grant type is used for highly privileged applications. This flow is implemented only when the other flows are not viable. This grant type is suitable for clients capable of obtaining the resource owner’s credentials (username and password, typically using an interactive form). It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.

The client will ask the user for their authorization credentials (usually a username and password). The client then sends a POST request with following body parameters to the authorization server:

• grant_type: which contains the value password
• client_id: which contains the client’s ID
• client_secret: which contains the client’s secret
• scope: which contains a space-delimited list of requested scope permissions
• username: which contains a user’s username
• password: which contains a user’s password

4. Client Credentials Grant
This grant type uses the client’s credentials to get the access token. The authorization server authenticates the client credential and issues an access token.

The client sends a POST request with the following body parameters to the authorization server:

• grant_type: which contains the value client credentials
• client_id: which contains the client’s ID
• client_secret: which contains the client’s secret
• scope: which contains a space-delimited list of requested scope permissions

5. Refresh Token Grant
This grant type uses the refresh token to refresh the access token. The authorization server issues a refresh token to enable the client to refresh the access token when the access token is expired.

The client sends a POST request with the following body parameters to the authorization server:

• grant_type: which contains the value refresh token
• refresh_token: which contains the refresh token
• client_id: which contains the client’s ID
• client_secret: which contains the client’s secret
• scope: which contains a space-delimited list of requested scope permission

Conclusion

OAuth 2.0 is the most secure and advanced way to implement open authorization. OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.