Authentication is the process of proving your identity to third party services. In its simplest form you sign up to an application by providing your credentials and use these credentials (most of the time an email address and a password ) to log in back to the application.
On the other hand authorization is the process of giving someone or another application permission to do something or to have something. Most of the cases, permission is given by an application on behalf of you to another application to use its resources. For example as a user you want to login to Spotify using Facebook. In this case Facebook is giving access to your resources in Facebook, with your consent, to Spotify.
An Industry-Standard Protocol
Auth 2.0 is an industry-standard protocol for authorization. Developed and maintained by IETF (Internet Engineering Task Force). The OAuth 2.0 authorization framework provides authorization flows for web applications, desktop applications and smart-home applications.
From the perspective of the user, it simply allows users to grant websites and applications access to their information without giving their passwords.
In more technical level, as it is defined in RFC 6749, OAuth 2.0 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.
For the sake of further reference and simplicity it is time to clearly define the roles OAuth uses as it is stated in RFC documentation:
resource owner - An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
resource server - The server that is hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
client - An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
authorization server - The server that is issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
A Comprehensive Understanding Of OAuth
Since we know the stakeholders from the perspective of OAuth, to build a comprehensive understanding of OAuth we can now highlight what was the problem before OAuth took place. And how it intends to solve these problems.
In the traditional client-server authentication model if the client wants to use some of the server resources it has to do so by providing the resource owner’s credentials. But it creates myriad different problems and limitations.
Clients (or third-party applications) are required to store the resource owner’s credentials for future use. Typically a password in clear-text.
Servers have to support password authentication which is a security weakness on its own.
Third-party applications (servers, clients, etc...) gain broad access to the resource owner’s protected resources, leaving resource owners without ability to restrict duration or access to a limited subset of resources.
Resource owners cannot revoke access rights of the individual third parties without revoking access to all third parties.
Compromise of any third-party application results in compromise of the end-user’s credentials and all the resources protected by these credentials.
OAuth addresses these issues by abstracting the authorization layer and separating the role of the client from that of the resource owner. Any access request from a client issued with a different set of credentials than those of the resource owner.
These different sets of credentials are defined as an “access token” which denotes a specific scope, lifetime, and other access attributes. These tokens are issued by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
OAuth can be complicated to understand at times if you are not familiar with the authorization flow. It can even be more complicated to implement within an application as an authorization layer. No worries though, we will explain the OAuth2.0 authorization flow with its different components when the time is right.
In the forthcoming articles, we will discuss first the history of OAuth. This will help us to understand what was the problem with authorization flows before OAuth and how different companies tried to provide solutions and what is the OAuth authorization flow.
Secondly we will see the differences between OAuth 1.0 and OAuth 2.0 and which specific improvements have been made and what possible risks and problems we are still facing. We will then discuss why OAuth 2.0 goes hand in hand with OpenId as an Authentication/Authorization duo.
At the end we will try to break down the simple implementation of OAuth2 and OpenId with code examples.