How does OAuth Work

Authorization key: A certificate generated by the system which helps a user access the required resource or service is known as the Authorization key.

Access key: After a user is authorized an access key is generated for the service that the user wishes to provide access to. This access key describes what permissions the service has over the user’s information.

Each OAuth flow generally contains four components –

1. Resource Server: This is the service where the user data is stored.
2. Resource Owner: This is an end-user or service that owns the data on the resource server
3. Client: The service that wants to access your data is known as the client.
4. Authorization Server: The brain of OAuth, which helps facilitate the transactions.

Let’s explain OAuth with an example – Suppose you (The Resource Owner) are subscribed to an image storing site (The Client) and you want it to automatically take all your photos from your Facebook (The Resource Server) profile and store it in its server. You trigger an OAuth flow between the image site and Facebook. This would redirect you to a Facebook page where you authorize yourself (If required) via the Authorization Server and the authorization key. You then set the permission that the image service can access your images but not post on your behalf on your Facebook profile. After you set these and click accept, the Authorization server provides an Access Key to the client for usage while accessing the information. This not only secures the flow but involves no exchange of user credentials.

However, not every flow has two keys; it may have just one as well depending on the need. Let’s look at some of the different types of OAuth flows below –

1. Authorization code flow: This flow consists of both the keys (access and authorization) which enables secure transactions. After verifying with the authorization key that the user is verified, and an access key is generated for accessing allotted information. If a user tries to access another application a new authorization key must be generated as the old one is no longer valid.
2. Implicit flow: This flow consists of only access keys. Generally, an access key is generated after verifying the authorization key but here authorization will not take place. The user is not verified. It is recommended for native apps and javascript apps in which there is no encryption of keys during transmission. Since anyone can transfer the access key and get access this is not secure. It does have its use cases though, for example, when a graphics design site needs to check if you are authorized to see premium content that is hosted on another service, while you are logged in already would use this flow. Thus this is used if there is a high degree of trust between the resource owner and client.
3. Client Credential flow: This flow has no involvement from the user i.e. Resource Owner. The client will provide the authorization key for the user and the accesses it requires to the authorization server. The authorization server will then respond with the appropriate access key. This is generally used for machine-to-machine communication. An example of this is a trip aggregation site that collects flight information from different portals and presents you with the lowest cost ones.

Do note OAuth has two specifications OAuth 1.0 and 2.0 and when we say OAuth we mean OAuth 2.0. Another key point to note is that the 2.0 specification is not backwards compatible with the 1.0 specification.

How we can help?

OAuth technology, while looking seemingly easy, is infact complex and confusing. With a trusted partner like SecurDI that has years of experience in this space, we can help you strategize and design the appropriate OAuth flows for your organization needs using leading enterprise tools. Our seasoned professionals can help you choose the right technologies and vendors for your targeted needs to ensure you get the required success.

– Authored by Navya Molugu

Background vector created by rawpixel.com – www.freepik.com