What is OAuth

OAuth is becoming a common word in corporate's dictionary. For some people this means security, for some it means tokens and for some it means scopes, grants and client_ids and for some it means a whole new world. This is because OAuth is as deep as an ocean and how deep you go into it depends on your passion and interest.

In simplistic terms , OAuth is primarily used for authorizing access to a resource for limited use. It is like you handover the key of your car to a vault service to drive to the parking and back. So, the resource owner (in this case the car owner) can choose the access to the resource (car). OAuth is a framework developed by IETF. In the web world, OAuth works with https.

The biggest advantage of OAuth is that it solves the issue of giving away the usernames and password to gain temporary access. In a typical delegation flow, a client opts for an access token from an authorisation server. This access token is used for its request to the resource server. The resource server then redirects to the resource owner to request for the access. The resource owner ( which could be a server application too) validates the access for the scopes and claims and based on the access rights, either the access is granted or denied for the resource use. The grants can be for a limited scope or a full scope. As an example, one client can be granted read and write access to a resource, while another client can be granted only read to the same resource.

The most important part of OAuth is the way token flows around and the various actors involved. The actors include a client, a resource owner, an authorisation server and a resource server. In addition there are grant types which decide in which scenario which type of flow is used. In all there are 4 grant types namely client credentials, password, authorization code and implicit.

In today’s world, OAuth 2.0 is widely used. In the API world, OAuth 2.0 is becoming the de-facto. The next version is OAuth 2.1 is drafted and under review. OAuth 2.1 makes the grant types much simpler as implicit type and password would be omitted.

Looking deeper in the token, there can be few types of these too. There is the access token, id token and refresh token. The lifetime of each token is different, refresh token normally live on for few days as compared to access token which can have a life of few hours. The access token and id token can be in a format of JWT (JSON Web Token). JWT has its own standard and has support for various algorithms. JWT can contain custom claims which is commonly seen in API request payloads to authorize access.

In the above primer, I wanted to only touch upon OAuth from the surface. There is a lot more depth with various RFCs around these. If you want to read further than nothing like the RFC where this started from - https://tools.ietf.org/html/rfc6750