1. Introduction
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 is an open protocol (or you can say a set of specifications) that allows developers to authorize users from web, mobile and desktop applications. This specification and its extensions are being developed within the IETF OAuth Working Group.
One important point to note about OAuth 2.0 is that the specifications don’t specify authentication. However, authentication is very integral part of OAuth 2.0 because authentication of a user is the first step before authorization.
OAuth is sometimes confused with SAML. SAML is primarily an authentication system used for single sign-on. Whereas OAuth 2.0 is an authorization system that has authentication layer on top of it (OpenID Connect, or OIDC).
In OAuth 2.0, developers can easily delegate the authentication and authorization of users to some other system.
2. Why OAuth was required?
To understand OAuth, you need to understand the problem OAuth solves. Before OAuth, the common way of authentication was direct authentication pattern.
2.1 Direct authentication pattern
In direct authentication pattern, both the Requestor and Service participate in a trust relationship. Credentials are shared and validated directly between the Requestor and the Service. An example of this pattern would be a custom authentication implementation that requires the Requestor to provide a username and password. Another example would be an Intranet application where all users belong to the same active directory.
Following diagram shows a typical direct authentication pattern:
Before OAuth, applications would ask for username and password typically in a form to gain access to user data, for example the username and password for a Google account to access Google account data. Users would not want to grant any other application full access to their account. Users may want to grant read only access to the contacts but not any access to update the account settings.
When using OAuth, the users log into a platform and provide their credentials. The platform generates tokens which are used to grant access and perform actions in one or more other applications. These applications may be managed by the same people who manage the authorization platform or by third parties.
Using OAuth is easier to manage for developers because:
- a token having a limited lifetime is used for authorization. This removes the need of sharing credentials and hence improves security.
- no need to maintain database to store username and password. Developers only need to integrate OAuth 2.0 in their application.
OAuth makes it easier to get access to protected data from a resource server without asking users to log in with passwords.
3. Understanding OAuth with a scenario
To understand OAuth, let us assume that you have a Gmail account and you want to analyze data about your emails. There is an app which provides such services. This application can give you an overview about your emails by analyzing the emails. For example, this application can tell you the count of emails sent every month, average word count, with whom you interacted most etc. To do so, this application needs to access your Gmail data. Lets name this application as GmailAnalyzer.
3.1 Without OAuth 2.0
Without OAuth, Gmail user has to share his Gmail credentials (username and password ) with the GmailAnalyzer application. The GmailAnalyzer application will invoke the Gmail APIs using these credentials to get the data for analysis.
This is not secure as user has to share his username and password with a third party. Since GmailAnalyzer application has user’s credentials, the application can perform any other unintended operation like sending an email, changing password etc. This approach has following problems and limitations:
- Third party applications are required to store the user’s password for future use.
- Third party applications get unlimited access because of having the password.
- If third party is compromised, all of the user data is compromised.
- User can not revoke access of a particular third party without revoking access of all third parties as he has to change the password.
3.2 With OAuth 2.0
The Gmail user does not share credentials with GmailAnalyzer application. Instead the user will ask Gmail to provide temporary access token to the GmailAnalyzer application with limited access to read data.
With this approach, the user does not have to share his credentials with third party and the GmailAnalyzer has limited data. This is a better approach in comparison to sharing credentials with a third party.
4. Conclusion
We discussed what OAuth is and what problem OAuth solves. In upcoming tutorials, we’ll discuss the flow of OAuth 2.0 and roles involved in OAuth. We’ll then move to the implementation of OAuth with Spring security.