There’s fair chance you would have read through the chapter on authentication before landing here. If you have, then you’re going to glide through the first few lines here. If you haven’t, it’s better to do so because authentication precedes authorization as a process and an understanding of it is crucial to understand authorization as a process.

So, authentication is the process when a person logs into a network using his or her credentials and these credentials are matched against the ones stored in the network’s authentication server database. In simple words, it is checking if the username and password combination are correct. Authorization follows this process and is based on protocols which tell the network what level of access a person should be provided.

An example of authorization we all witness on a regular basis is on social networks. Third party applications regularly seek your permission to draw details from your social media accounts or post on your behalf, which is a very common scenario of authorization. Typically, the situation would form this way:


  1. You access a third party application which asks you to login with your social identity.
  2. You choose to Login with Facebook and enter your Facebook identity credentials.
  3. This is the authentication step where the third party app lets you in by checking if the Facebook credentials you presented match with an existing account.
  4. Once authenticated, the app requests your permission to access your profile, post on your behalf etc.
  5. If you permit, you enter the authorization step whereby you are authorizing the app to access normally classified information on your profile, post on your behalf - which typically only you would do - and perform any other functions.

There are access tokens and protocols involved in this but suffice to say that the above is a broad high level view of what authentication and authorization in tandem look like. Further, it must be clear by now that authorization is specification of access rights to individual users and even delegated access on behalf of users.

Authorization is different from Single Sign-On and Federation as a whole performing a wholly different function. Access tokens figure in both but Single Sign-On uses an access token from an site where a user has been authenticated to gain access to another web property for the same user. Authorization, on the other hand, just provides access on the same network.

Types of Authorization

Authorization protocols can be built on different platforms. Simple authorization protocols exist with access control just being based on the success of authentication. Additionally, there are role and claims based authorization protocols as well. Role based authorization controls access based on the role of the user in the overall hierarchy while claims based authorization is more of a cutoff system where access is controlled based on values held by a user’s claims (a name value pair associated with the profile). There are other systems as well and which sort of protocol is employable depends on the nature of the environment of application.

What’s OAuth all about?

Well, this is the business end for this post. From the perspective of Customer Identity and Access Management (cIAM), OAuth is a pretty important protocol. In basic terms, OAuth is an authorization protocol that helps applications gain delegated access to resources on behalf of a user. Recall the situation elaborated in the first few paragraphs of this post. OAuth helps accomplish the same task with ease.

It is important to observe that the primary use case here is delegated access for third party apps mostly applied in social media. OAuth helps by letting users delegate access without having to share their credentials (more specifically passwords), However, despite being an authorization protocol, OAuth can also be used for authentication in a process called OAuth based pseudo authentication. But mind that authentication is not the primary use case for OAuth so designing a system for authentication on the basis of OAuth can lead to some major issues.

So how does OAuth work really? You must be familiar with the identity provider and service provider framework. If not, it’s alright. We’ll do a small primer here. An identity provider is an issuer and owner of identities while a service provider uses these identities to provide privileges to an identity holder. Think of it like this: You own a website and provide options for registration with Facebook identities. So you are the service provider because you don’t own the rights to the identity but are leveraging those owned by Facebook. And clearly Facebook is the identity provider.

In an OAuth use case, the service provider seeks authorization through the user (who is the identity holder) to specific resources like the user’s profile information. This request is sent to the identity provider which in turn makes seeks the user’s assent. If approved, the identity provider issues access tokens to the third party, or service provider, which can then be used to access the profile information. During this process, if the user is not already authenticated, the identity provider may also prompt the user for authentication just prior to seeking assent. You can easily understand that authentication is also being carried out as part of a request for authorization. Clearly, though, authentication is not the primary use case for OAuth.

For authentication and authorization, the OpenID Connect works well with the OAuth framework as an authentication layer on top of OAuth. In fact, it can even be used to draw basic profile information in a REST environment without even having to use OAuth again. OAuth, on the other hand, can be employed for more complex operations.