What The Tech?: The OAuth Basics

You might not know it, but you’ve probably used OAuth at least once in your life – especially if you’re a fan of connecting your social media accounts to apps and websites. But you also might not be entirely sure what it means or does. As it’s name implies, you’ve probably guessed that OAuth probably has some relationship with either authorisation or authentication, right? But there’s quite a difference between the two and what they do. Keep reading to find out more as we go through the basics of OAuth.

What is OAuth?

When we speak about OAuth, it’s in relation to authorisation, not authentication, and this is probably the easiest way to start thinking about its benefits and uses. Originally, OAuth was created for one service to authorise another service not to authorise a person. We’ll give you an example – think of the employee recruiting system for a company. There are two options in the system to enter profile details. You can do one of the following:

1. Create the user account and enter all the professional qualifications manually into the system.
2. Get personal details and professional qualifications from LinkedIn (of course this is only if the user has already registered in LinkedIn).

If you’re the type to use the second option because it quickens the process then congrats! You’ve used OAuth before. So how does it all work then? In order for you to upload your qualifications to a recruitment system hassle-free, the employee recruiting system needs to connect to your LinkedIn profile. To do this, the system needs LinkedIn’s authentication. But wait, there’s more: to get the LinkedIn authentication, the system first needs your LinkedIn account credentials.  

Naturally, people can be wary of giving their credentials. Sometimes it takes too long, or we may not trust the site, OAuth helps us with this. As the recruiting system tries to access the LinkedIn profile on behalf of the user, this means one service is accessing another service on behalf of the user, this standard practice is called OAuth. There’s actually a OAuth 1.0 version, but if you want the latest and more widely used version, then OAuth 2.0 is for you. Still following? Great, let's see what else we can do with it...

Can OAuth make exceptions?

Still taking the recruiting system example, a good question to ask is 'do we need to allow this recruiting system to access the full profile details in LinkedIn, including all of your connections?' No, that’s not necessary as the recruiting system only wants the professional qualifications and some of the personal details including mobile number, email etc. So, we need to provide limited access to the recruiting system. That is called access delegation in OAuth.

To use the OAuth function, the user needs to be a registered user in this recruiting system and LinkedIn. When the user asks to connect their LinkedIn profile to the recruiting system, the system will then call LinkedIn and request the profile of the relevant user. Then, LinkedIn goes to the user and gets consent from the user to share their details with the system. For example, LinkedIn should display details of the recurring system and permissions that are being requested by the system. If the user gives the consent to access the profile, then LinkedIn returns the token called authorisation token (key with limited permission) to the recruiting system and redirected to redirect URL which received with initial request. Ta-da! That’s how an OAuth call flow initiates.

Terminology

• Resource (Protected Resource) –The thing which needs to be accessed by an application, in the above recruitment system scenario, the resource is the profile details.
• Resource Owner -Who owns the resource. This is the entity that can grant the access to protected resource. In our previous example, this is the user.
• Resource Server – The server that holds the protected resource. In above scenario that is LinkedIn Server Profile API.
• Client- The application which needs access to the protected resource. Here the client is the recruiting system.
• Authorisation Server – The server which is responsible for the authorisation, it also issues access tokens to the client. The resource server and the authorisation server are usually coupled and sometimes the same server can act as both.

Stay tuned for Lifting the Lid on OAuth: Part 2, where we'll delve into OAuth call flows.

Like what you've read or want more like this? Let us know! Email us here or DM us: Twitter, LinkedIn, Facebook, we'd love to hear from you.