OAuth
Introduction
OAuth which stands for Open Authentication is an open standard authorization protocol or framework for access delegation, used by internet users as a means to grant websites or applications access to their information on other websites without giving them passwords. This protocol is utilized by companies like google, amazon, Microsoft, facebook, and twitter to permit their users to share information about their account with other applications or websites.
OAuth provides clients with a secure delegation to the resources on a server on behalf of the owner of the resources. It creates a process for resource owners to give permission to third party apps or sites to access their server resources without having to provide any credentials. This mechanism was specially designed to work with hypertext transfer protocol (HTTP), OAuth majorly enables access tokens to be issued to third-party clients by an authorization server, with the resources owner’s approval. The third-party then utilizes the access tokens to get into the secured resources hosted by the resource server. OAuth 2.0 in particular provides specific authorization flows for websites, Desktop application, Mobile desktop and Smart devices.
OAuth started in the month of November 2006 when Blaine Cook was creating the Twitter OpenID implementation. On the other hand, Ma.gnolia needed a solution to enable its members with OpenIDs to give permission to Dashboard Widgets to access their service. Cook, Chris Messina and Larry Halff from Ma.gnolia had a meeting with David Recordon to talk about using OpenID to delegate authentication on Twitter and Ma.gnolia APIs. This meeting came to the conclusion that there were no open standards for API access delegation.
In April 2007, the OAuth discussion group was established for a small group of implementers to draft a proposal for an open protocol. Google’s personnel DeWitt Clinton heard about the OAuth project and expressed his keen interest in the support of the effort. In July of the same year, the team drafted the initial specification. Eran Hammer contributed and coordinated the many OAuth suggestions creating a more formal specification. On December 4th 2007, the OAuth core 1.0 final draft was released.
During the 73rd Internet Engineering Task Force (IETF) meeting which was held in Minneapolis in November 2008, an OAuth BoF was held to discuss the induction of the protocol into the IETF for further standardization practice. The event was well graced and a wide range of support was given to the idea of formally creating an OAuth working group within the IETF.
OAuth 2.0 framework was published on October 2012, in consideration to additional use cases and extensibility requirements gathered from a wider IETF community. Although this was built on the deployment experience of the version 1.0, the version 2.0 is not backwards compatible with the previous version. It was published as RFC 6749 and the bearer token usage as RFC 6750.
The authorization framework OAuth 2.1 consolidates functionality in the RFC OAuth 2.0 for native apps, proof key for code exchange, browser based apps, OAuth security best current and Bearer token usage.
One of the biggest criticisms of the OAuth version 2.0 is the fact that the standard intentionally ignores encryptions, signatures, client verification or channel binding but rather implored clients to use external protection protocols to provide those features.
Security issues concerning OAuth
On the 23rd of April 2009, a session fixation security flaw in the OAuth version 1.0 protocol was reported. It affected the authorization flow in the OAuth core 1.0 section 6. Version 1.0a of the protocol was released to combat the problem.
In January 2013, the IETF released a threat model for OAuth version 2.0. Open Redirector was one of the threats which was outlined. In early 2014 a variant of this threat was observed and described under the alias Covert Redirector by Wang Jing.
During the months of April and May 2017, about a million users of the google service Gmail were disturbed by an OAuth based phishing attack. The affected users received a mail posing to be from a known colleague or classmate wanting to share a document on google docs. Those users who clicked the link were redirected to a malicious third-party app called Google Apps where information about their resources were collected. Within an hour, Google stopped the attack and advised its users that clicked the link to revoke such access and change their passwords.
Uses
- It can be used as a mechanism for authorizing access to secured RSS/Atom feeds.
- It enables an end user’s account information to be used by third party services without exposing the users account credentials to the third party.
Leave feedback about this
You must be logged in to post a comment.