OAuth

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?

  

  Abstract protocol flow. Source: Anicas 2014.

  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 flow

  Though 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?

  

  Use of endpoints as part of authorization code flow. Source: Jenkov 2014.

  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

References

1. Anicas, Mitchell. 2014. "An Introduction to OAuth 2." Digital Ocean. July 21. Accessed 2017-05-10.
2. Bradley, John. 2012. "The problem with OAuth for Authentication." Thread Safe. January 29. Accessed 2017-05-10.
3. Grossbart, Zack. 2017. "What You Need To Know About OAuth2 And Logging In With Facebook." Smashing Magazine, May 2. Accessed 2020-07-22.
4. Hammer, Eran. 2009. "History." Hueniverse. December 20. Accessed 2018-09-13.
5. Hammer, Eran. 2012. "OAuth 2.0 and the Road to Hell." Hueniverse. July 26. Accessed 2017-05-10.
6. Hammer-Lahav, Eran. 2007. "OAuth Introduction." OAuth.net. September 5. Accessed 2017-05-08.
7. Hardt, D. ed. 2012. "The OAuth 2.0 Authorization Framework." RFC 6749, IETF. October. Accessed 2017-05-08.
8. Hofstetter, Daniel. 2011. "2-legged vs. 3-legged OAuth." Cakebaker.January 10. 2017-05-11.
9. IETF Datatracker. 2017a. "Web Authorization Protocol (oauth)." April 19. Accessed 2017-05-08.
10. IETF Datatracker. 2017b. "Document Search: oauth." April 19. Accessed 2017-05-08.
11. Jenkov, Jakob. 2014. "OAuth 2.0 Endpoints." Jenkov.com. June 15. Accessed 2017-05-10.
12. Kocen, Mitchell. 2017. "Securing Your API with OAuth." StrongLoop. March 17. 2017-05-11.
13. Lightfoot, Jaime. 2016. "Authentication and Authorization: OpenID vs OAuth2 vs SAML." Atomic Object. May 30. Accessed 2017-05-11.
14. Lightner, Rob. 2011. "How to revoke Facebook app permissions." CNet, December 26. Accessed 2020-07-22.
15. Low, Aloysius, and Seth Rosenblatt. 2014. "Serious security flaw in OAuth, OpenID discovered." CNet. May 2. Accessed 2017-05-11.
16. Messina, Chris. 2007. "OAuth logo." Wikimedia Commons. December 13. Accessed 2017-05-08.
17. Mike. 2016. "OAuth vs. SAML vs. OpenID Connect." Gluu. December 7. 2017-05-11.
18. Millman, Rene. 2016. "Researchers find two flaws in OAuth 2.0." SC Magazine UK. January 8. Accessed 2017-05-11.
19. Nidhishah. 2013. "Low Hanging Threats to OAuth Security." HPE Community Blog. August 15. Accessed 2017-05-11.
20. OAuth.com. 2017. "Differences Between OAuth 1 and 2." Accessed 2017-05-11.
21. OAuth.com. 2017b. "Authorization vs Authentication." August 10. Updated 2018-07-12. Accessed 2020-07-22.
22. OAuth.net. 2009. "OAuth Core 1.0 Revision A." June 24. Accessed 2017-05-11.
23. OAuth.net. 2017. "OAuth 2.0." Accessed 2017-05-08.
24. OAuth.net. 2020. "Code." Accessed 2020-07-22.
25. OAuthLib Docs. 2015. "Frequently asked questions." April 14. 2017-05-10.
26. OpenID.net. 2017. "OpenID Connect FAQ and Q&As." Accessed 2017-05-11.

Further Reading

1. Anicas, Mitchell. 2014. "An Introduction to OAuth 2." Digital Ocean. July 21. Accessed 2017-05-10.
2. Parecki, Aaron. 2014. "OAuth 2 Simplified." Accessed 2017-05-11.
3. Trapp, Mark. 2012. "OAuth for Dummies." September 17. Accessed 2017-05-10.
4. Nijikokun. 2016. "The OAuth Bible." September 6. Accessed 2017-05-10.
5. Mangal, Agraj. 2013. "OAuth 2.0 - The Good, The Bad & The Ugly." Envato Tuts+. July 12. Accessed 2017-05-10.
6. Hardt, D. ed. 2012. "The OAuth 2.0 Authorization Framework." RFC 6749, IETF. October. Accessed 2017-05-08.

Article Stats

Author-wise Stats for Article Edits

Author

No. of Edits

No. of Chats

DevCoins

sangeetha-prabhu

1

0

1479

arvindpdmn

4

0

37

devbot5S

1

1

16

DevCoins due to articles, chats, their likes and article hits are included.

Cite As