# OAuth

## Summary


OAuth is an authorization framework that allows a third-party application to access private resources of a user when those resources are stored as part of another web service. For example, a user has an account with GMail or Facebook. The user visits a gaming platform that requests access to the user's basic profile on GMail or Facebook. OAuth allows the user to authorize this gaming platform to access the profile. 

The strength of OAuth lies in the fact that the user's credentials (username, password) are not shared with third-party services. Such credentials are used only between the resource owner (user) and the authorization server. Thus, OAuth is for authorization, not authentication. In addition, the user can at any point revoke this authorization.

## Discussion

### Why was OAuth invented in the first place?

Back in 2006, Blaine Cook was investigating a means to grant third-party applications access to Twitter API via delegated authentication. He considered using OpenID for this purpose but found it unsuitable. The idea was that users should not be required to share their usernames and passwords to third-party applications.

There were at the time other frameworks but they were not open standards: Flickr Auth, Google AuthSub and Yahoo! BBAuth. OAuth was thus invented as an open framework for authorization without even specifying the methods of authentication. In fact, it's been said that OAuth was written by studying and adopting the best practices from these early proprietary methods. 


### What are the available OAuth roles?

Four roles are defined in the standard: 

    + **Client** is the application requiring access to protected resources.
    + **Resource Owner** is the entity owning the resource. It's usually a person, called end-user. Resource owner gives authorization to client to access protected resources.
    + **Authorization Server** does authentication of the resource owner and handles authorization grants coming from the client. It gives out access tokens.
    + **Resource Server** manages protected resources based on access tokens presented by clients.As an example, a gaming application (client) requires the profile of a gamer (resource owner) from her GMail account. Access to the gamer's GMail profile (protected resource) is authorized by the gamer. The GMail service encapsulates both the authorization and resource servers. Implementations have the choice to combine authorization and resource servers into a single server, but they might just as well be different servers. 


### Could you briefly describe the protocol flow?

OAuth specifies different authorization grant types, each of which has its own flow. We can summarize the flow as made up of these steps: obtain authorization from user, exchange this authorization for an access token, use the token to access protected resources. 

Delving into the details, OAuth flows can be related to the level of confidentiality involved. If the client is a web application, then it's a confidential client since client ID and secret key are kept on the client server. If the client is a user-agent (web browser) or a native application running on a device with the resource owner, then it's a public client. From this perspective, we can look at flows in this manner: 

    + **Confidential**: client credentials flow, password flow, authorization code flow
    + **Public**: implicit flow, password flow, authorization code flowThough it's more common to talk of grant types these days, the terms two-legged flow and three-legged flow are still in use. With the former, the resource owner is not involved, as in client credentials flow. With the latter all three (resource owner, client and authorization server) are involved. 


### What essential data are exchanged for authorization?

Every client must have a client ID and a client secret key. Sometimes these are called consumer ID and consumer secret key. The client will also have a redirect URI. This is the endpoint where the authorization code will be received by the client and subsequently exchanged for an access token. This tuple of client ID, secret key and redirect URI is generated or configured in advance on the authorization server, what is called client registration. Authorization will fail if these do not match.

Access token is the one that's presented to the resource server after a successful authorization. Access token simply allows access to protected resources. The resource owner may choose at any point to revoke access at the authorization server. A token can also expire, in which case the client can request a token refresh if refresh is allowed. 

In the case of password flow, authorization will be based on the resource owner's username and password. From a security standpoint, this flow makes sense only if the resource owner trusts the client enough to give out her username and password. 


### Which are the endpoints defined in OAuth?

An endpoint is nothing more than a URI. The standard defines the following endpoints though extra endpoints could be added: 

    + **Authorization endpoint**: Located at the authorization server, this is used by the client to obtain authorization from the resource owner. Resource owner is redirected to authorization server via a user-agent (typically the web browser).
    + **Redirection endpoint**: Located at the client, this is used by the authorization server to return responses containing authorization credentials to the client via the user-agent.
    + **Token endpoint**: Located at the authorization server, this is used by the client to exchange an authorization grant for an access token.The typical call flow, at least for authorization code grant type, invokes the endpoints in the order of Authorization, Redirection and Token. In the case of implicit grant type, the order is Authorization and Redirection endpoints. The Token endpoint is not involved since the Authorization endpoint implicitly returns an access token. 


### Are there open source implementations of OAuth?

OAuthLib is an open source implementation in Python. Hydra is an implementation in Go. It covers OAuth and OpenID Connect. In Java, we have Spring Security OAuth and Apache Oltu. The latter includes OAuth, JWT, JWS and OpenID Connect. From Google, there's Google OAuth Client Library for Java. Anvil Connect supports OAuth, JWT and OpenID Connect. 

We have keep in mind that these implementations may be specific to client or server or both.


### How would you compare OAuth with OpenID Connect and SAML?

OpenID Connect (OIDC) is an identity and authentication layer that uses OAuth 2.0 as the base layer for authorization. As an ID token it uses a signed JSON Web Token (JWT), also called JSON Web Signature (JWS). It uses REST/JSON message flows. OIDC best suited for single sign-on apps while OAuth is best for API authorization. 

In some use cases, OAuth 2.0 may be used by implementors as a means of pseudo-authentication, by assuming the entity owning the access token is also the resource owner. Eran Hammer-Lahav summarized the difference between OpenID and OAuth nicely (authentication vs authorization), 

> While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all.

Security Assertion Markup Language (SAML) offers both authentication and authorization. What is called a token in OpenID and OAuth terminology, is called an assertion in SAML. Assertions (structured in XML) contain statements that fulfil the purpose of authentication and authorization. SAML may not be suited for mobile apps. 

As a simplification, we could see OIDC as a combination of OAuth and SAML. 


### What are OAuth extensions?

OAuth allows extensibility in terms of authorization grant types, access token types, and more. This will allow OAuth to interwork with other protocol frameworks.

Website OAuth.net considers three RFCs as part of the OAuth 2.0 Core: 6749, 6750, 6819. It then lists a number of OAuth extensions. Likewise, a search on IETF Datatracker yields all documents that pertain to OAuth. 


### How does OAuth 1.x compare against OAuth 2.0?

OAuth 2.0 uses SSL/TLS for security. With OAuth 1.x, each request had to be secured by the OAuth implementation, which was cumbersome. In this sense, OAuth 2 is simpler. OAuth 1.0 suffered from session fixation attacks. Such a flaw does not exist in OAuth 1.0a and above. 

OAuth 2.0 uses grant types to define different flows or use cases. OAuth 1.x worked well for server-side applications but not so well for browser web apps or native apps. OAuth 2.0 is not compatible with OAuth 1.0 or 1.0a (sometimes called 1.1). A deeper technical comparison of versions 1.x and 2.0 is available at OAuth.com. 

Controversially, it's been mentioned that OAuth 2 is "more complex, less interoperable, less useful, more incomplete, and most importantly, less secure." 


### What are the problems with OAuth?

One of OAuth's original creators, Eran Hammer, claimed that OAuth 2 is more complex and less useful than its earlier version. It's been "designed-by-committee" with enterprise focus. He claims OAuth should have been a protocol rather than a framework. The end result is too much flexibility and very few interoperable implementations. 

In terms of security risks, one analysis showed how developers can mistakenly use OAuth for the purpose of user authentication. In 2014, the "Covert Redirect" vulnerability was discovered where phishing along with URL redirection can be used to gain access to protected resources. This can be solved by having a whitelist of redirect URLs on the authorization server. In 2016, researchers discovered that man-in-the-middle attacks were possible with OAuth and OpenID Connect. Because OAuth 2.0 uses TLS, it doesn't support signature, encryption, channel binding and client verification. 

## Milestones

Nov  
2006

Blaine Cook starts looking at OpenID but wants a better delegated authentication method for the Twitter API. 

Apr  
2007

OpenAuth Google group is started but when AOL releases their own protocol named OpenAuth, this group changes its name to OAuth in May 2007. 

Dec  
2007

OAuth Core 1.0 final draft is released. 

May  
2009

OAuth Working Group is created at IETF. One of the creators of OAuth later commented that bringing OAuth into IETF was a mistake. 

Jun  
2009

OAuth Core 1.0 Revision A is released. It fixes the session fixation attack. 

Apr  
2010

IETF releases RFC 5849 that replaces OAuth Core 1.0 Revision A. 

Oct  
2012

OAuth 2.0 is released by IETF as RFC 6749.