OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006.
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.
Disadvantages-
Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions.
Allowing other websites to access a resource owner’s data stored in some other website without giving the Password.
This is an example in which Yelp wanted to solve the issue of delegated authorization and incorporated a method with which a user could let Yelp access some part of his/her data from his preferred mail ID by entering their mail ID and Password for the same.
This is an example in which Facebook wanted to solve the issue of delegated authorization and incorporated a method with which a user could let Facebook access some part of his/her data from his preferred mail ID by entering their mail ID and Password for the same.
In the shown cases, a user will have to just trust Yelp or Facebook and believe that they keep his/her mail ID and password safe and also that they do not access any other information except what they asked for.
These were insecure and bad ways to implement delegated authorization and left the user’s credentials as well as his/her account at risk always.
In the given example, the user is asking Google to allow Yelp/Facebook to access only his contacts using Google APIs.
Here, after authenticating the user, Google API will grant access of the user’s contacts to Yelp/Facebook.
The following are real-life examples that involve a secure implementation of delegated authorization.
Here, Spotify wants to access some of the user’s Facebook data.
Taking an example of a user trying to login into LinkedIn using Gmail(Google) API and credentials-
There are two types of channels by which the whole process occurs.
OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., the ability to maintain the confidentiality of their client credentials):
Confidential: Clients capable of maintaining the confidentiality of their credentials (e.g., the client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.
Public: Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.
The authorization process utilizes two authorization server endpoints (HTTP resources):
Authorization endpoint — used by the client to obtain authorization from the resource owner via user-agent redirection.
Token endpoint — used by the client to exchange an authorization grant for an access token, typically with client authentication.
As well as one client endpoint:
Redirection endpoint — used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.
Steps:
We can see that the process in which Yelp/Facebook accesses Gmail contacts has dotted lines, which implies that it takes place via the Back Channel.
The solid lines represent the Front Channel.
An Authorisation Grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token.
It has the following types:
The authorization code is obtained by using an authorization server as an intermediary between the client and the resource owner.
Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server via its user agent, which in turn directs the resource owner back to the client with the authorization code.
Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization.
Because the resource owner only authenticates with the authorization server, the resource owner’s credentials are never shared with the client.
The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript.
In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.
When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client.
The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. The credentials should only be used when there is a high degree of trust between the resource owner and the client, and when other authorization grant types are not available.
The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.
Client credentials are used as an authorization grant typically 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.
Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client.
The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).
Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token.
A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client.
The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
Steps:
Apple users are falling prey to a sophisticated phishing campaign designed to hijack their Apple…
Hackers have been found leveraging weaponized virtual hard disk (VHD) files to deploy the notorious…
A security update released by ChatRTX on March 26th, 2024, addresses two vulnerabilities (CVE-2024-0082 and…
A new threat has emerged, targeting unsuspecting iPhone users through the seemingly secure iMefofferssage platform.…
Google patched seven vulnerabilities in the Chrome browser on Tuesday, including two zero-day exploits that…
The source code and documentation of the Italian anti-piracy platform Privacy Shield have reportedly been…