OAuth

What is OAuth?

OAuth, short for “open authorization,” is an open protocol commonly used to grant websites or apps access to user info stored on other websites, all without sharing passwords. With OAuth, a person can selectively and securely allow two websites to interact directly, with the goal of making a particular task easier. OAuth grants permission or authorization to access data, which is different from authenticating an identity (such as when a user logs into a service).

OAuth can be used in situations that involve a Web browser, a mobile app, or an Internet of Things (IoT) device, and is meant to streamline tasks like moving files, finding friends on a social media site, or changing the setting on a home thermostat. The service that receives the permission to access a user’s data can be given limited access to only some data, and varying capabilities (e.g. read-only or read-and-edit). OAuth is sometimes confused with the third-party login feature that allows a user to log into a site using Google or Facebook credentials. Third-party login, called “open ID connect” (OIDC), is just one specific application of OAuth. This article focuses on OAuth, but will also discuss the OIDC application of OAuth capabilities.

What does OAuth look like?

Here’s an example of OAuth in action. When you start an account at a social media service like LinkedIn, one of the first things the site or app will ask is if you want to connect your address book so LinkedIn can suggest other people you might add to your network. If you declare that your address book is in Gmail, LinkedIn will give you a portal to log into Google. If you proceed with logging into Google and authorize this address-book connection, LinkedIn will then collect the email addresses in your address book, and search for those addresses in LinkedIn’s database of registered users. This saves you the trouble of having to search for connections because your information can be directly imported from Gmail.

This authorization remains in place until you tell Google to revoke it, or until it reaches its expiration date. If you add email addresses to your Gmail account and want LinkedIn to run another search, you won’t need to reauthorize LinkedIn’s access to the Gmail address book.

This example illustrates a few advantages of OAuth:

• You can connect these services without having to share your Google login information with LinkedIn. This keeps your credentials stored in fewer places, and thus less exposed to the risk of a data breach.
• The process is streamlined for you. LinkedIn and Gmail handle the data sharing, with minimal effort on your part.
• You can revoke LinkedIn’s permission at any time.
• LinkedIn only gets access to the email addresses in your address book, and nothing else in your address book or in the email account in general.

How does OAuth work?

There are several parties involved, and several steps to setting up an OAuth data sharing situation. Some of these steps are visible, while others happen in the background (i.e. directly between the two services). The exact steps may vary based on what OAuth is being used for, but using the LinkedIn/Google example we can roughly explain OAuth through the lens of the parties involved, and the actual setup steps.

The involved parties

• Resource owner: The entity, usually a person, that wants to allow one service to access data on a different service.
• Client: The app or service that wants access to certain data, or to perform certain tasks for the resource owner. In our example, LinkedIn is the client because they want to access an address book stored in Gmail.
• Authorization server: The service (in this case Google) that receives an access request from the client, and verifies permission with the resource owner. The authorization server prepares the access token (like a key) that the client will use to access the requested data (email addresses) now and in the future.
• Resource server: The entity that actually has the data (email addresses) the resource owner would like to give the client access to. In some cases this is the same as the authorization server, but in others it might be different (in our example the resource server is Gmail).

The steps to set up an OAuth agreement

What follows is a general authorization code flow that represents what happens with OAuth. Note that there are many other, slightly different flows that have also been created for different scenarios.

1. You go to the LinkedIn website and ask LinkedIn to search for people you might know.
   • (The resource owner initiates the OAuth process by telling the client app that they want to do something using their data.)
2. LinkedIn tells Google that you want to share your Gmail address book with LinkedIn.
   • (The client pings the authorization server saying the resource owner wants the client to access certain data.)
3. Google verifies it’s dealing with LinkedIn and not an imposter, and what data is being requested.
   • (The authorization request contains the scope of the request and what data is being requested—email addresses—what the client is allowed to do with the data—download only—and where to return the authorization request—such as a URL like linkedin.com/callback. The authorization request also contains a code that both the authorization server and the client use to verify one another during any authorization process.)
4. Google passes a token back to LinkedIn.
   • (The authorization server gives the client a request token—a digital package that includes a restatement of the scope and a secret specific to this arrangement.)
5. LinkedIn shows a screen where you can log into Google, and confirm you want to share email addresses with LinkedIn.
   • (The resource owner sees an authorization screen that asks them to verify they want to permit the client the specified data access. When the resource owner validates the request, the validation also sends back the request token—along with scope and secret—as proof that nothing was misdirected during the validation process.)
6. Google records that you have granted LinkedIn permission to download email addresses from your Gmail account.
   • (The authorization server receives the validation with the request token, verifies all is as expected, and marks in their records that the resource owner confirmed the request.)
7. LinkedIn confirms that Gmail has everything it needs, and requests access to the email addresses saved in the address book. Gmail replies with a key that LinkedIn can use to access the email addresses for a certain period of time.
   • (The client can now formally submit the request token with a request for access to the resource server. The resource server sees that the request token was validated and issues an access token to the client. The access token details what data can be accessed, which permissions were granted regarding that data, and how long the access token is valid. The token doesn’t contain anything that specifically identifies the resource owner, only what data can be accessed.)
8. When you ask LinkedIn to run another search for friends, LinkedIn can access your address book without having to repeat all the steps above.
   • (The client can now use the access token to directly access the specifically permitted data on the resource server without needing repeated confirmation by the resource owner.)

How is OIDC different from OAuth?

OIDC, or third-party login, is an authentication protocol that’s built on the OAuth framework; the difference between the two isn’t always obvious. OIDC allows you to log into one service, such as Spotify, using credentials from another service, such as Google. The key difference is that OIDC authenticates you, while OAuth gives authorization to perform actions with your data on your behalf. Where an OAuth process results in an access token that contains data access permissions, an OIDC process results in an access token paired with an ID token that contains verification status of the user authentication (basically that you are who you claim to be), and maybe info about the user, like name or email.

When the service the user wants to access (Spotify) receives the ID token from the authenticating service (Google), they know the authentication is successful. The OIDC process doesn’t grant the accessed service any privileges regarding the user’s data on the authenticating service. Another outcome of this transaction is that the authenticating service also confirms the authenticity of the service being accessed.

Security and privacy risks with OAuth and OIDC

OAuth and OIDC both offer improved security. OAuth protocols result in not having to share credentials among services, and less exposure to data breaches; they also give the individual more refined control of how others use their data. The upside to using a third-party login (OIDC) when it’s available is it reduces the number of logins you need to keep track of, which in turn can translate to improved security habits (such as using strong, unique passwords).

But as with any advancements in security, the risks also evolve in response. With the OAuth process, hackers with stolen login credentials can inject a false URL into the process, diverting tokens intended for the client to the hacker’s websites. The hackers are then able to use the hijacked tokens to illegally access a user’s data.

With OIDC, hackers can trick an individual into using a fake third-party login screen in order to collect a user’s ID and password. With regard to privacy, using a third-party login gives Google or Facebook more data to collect on your activity, since they can now monitor your use of those apps and websites you’re logging into.