Lately, I have been interviewing candidates for a role that requires a deep understanding of OAuth. One of the questions I like to ask is
“Spotify has this really cool feature which shows me what podcast’s or songs my friends are listening to. All I need to do is allow Spotify to access my Google Contacts. Can you explain how this works with respect to Oauth?”
This Is one of those ‘What happens when you type www.google.com into your browser…’ type questions. It’s an open ended question that lets you answer in a way that exemplifies your understanding and depth. I am surprised by how few actually take the opportunity to do so.
So here is one way you could answer the question.
Before we delve into how this works, let us understand why delegated authorization is important.
Some time back, Yelp had a feature which would let you invite your friends onto the platform. The only problem - you had to type in your email credentials into Yelp to use the feature. There was no way for the user
to know what information would be accessed by Yelp
to revoke access (apart from changing your credentials)
Oauth provides a secure way for a user to allow 3rd party apps like Yelp or Spotify to access curated information from services like Google on their behalf. The user can explicitly view what accesses is requested and provide consent.
Meet the Actors
Since Oauth is a protocol, a good answer starts off by defining all of the actors that will be involved in using it. In this case the actors involved are:
Resource Owner (Me): The owner of the resource Spotify wants access to
Client (Spotify): The 3rd party application that wants access.
Resource Server (Google Contacts API): The server that provides the resource
Authorization Server (Google Accounts API): The authorization server which can grant/deny access to the resources.
Front vs Back Channel
Oauth distinguishes between two kinds of channels: Front-channel vs Back-channel
Front-Channel transactions happen via the Browser and typically involves the user. The data is visible in the URL(query parameters) and are not considered secure and hence. typically no secrets should be exchanged via Front-channel.
Back-Channel involves server-to-server communications. These are secured via HTTPs and not visible to the user.
The Flow
Step 1: Redirection (Front-channel)
When the user opts-in to the feature, Spotify redirects the user to Google’s authorization page where they are presented with a consent page:
Spotify is requesting access to :
Read your Contacts
Allow/Deny
This is a front-channel communication. Spotify send the following information to Google:
client_id → a unique identifier which let’s Google know that the request is from Spotify
response type → is set to ‘code’, which tells Google that Spotify is requesting an Authorization Code
redirect_url → where to send the response back to. If the user clicks Allow the response contains an Authorization Code.
scope → what permissions are being requested
Google authenticates the user if needed, and presents the user with a consent screen like the one shown above. If the user provides consent, Google sends the Authorization Code back to Spotify using the redirect URL
This code is an Opaque token which identifies the flow to Google. It is safe to send via front-channel as all of the information is stored on Google’s side.
Step 2: Exchange (Back-channel)
Spotify exchanges the Authorization Code for an Access Token. This is done securely via back-channel communication over HTTPs
Spotify calls the Google API with the following parameters:
client_id and client_secret → to authenticate itself to Google
code → the one that it just received
grant_type → is set to “authorization_code”
redirect_url → this should match the one sent previously and is used for verification
In response, Google provides the Access Token and optionally a Refresh Token.The Access Token can be an Opaque token or.a JWT token. The Authorization Code can only be used once.
Note: Oauth does not specify the format of the Access Token.
Step 3: Access (Back-channel)
Spotify reads User contacts via the Google Contacts API using the Access Token. This is done securely via back-channel communications over HTTPs.
If the Access Token has an expiry, Spotify uses the Refresh Token to request a new Access Token so that the user does not have to provide consent again.
Aspects of Security
There are several aspects of the protocol that makes this flow highly secure.
All sensitive information exchange is done via back-channel communications over HTTPs
The Authorization Code can only be used once. Even if this code is intercepted, it quickly becomes useless.
Access tokens are exchanged only after the client is authenticated. The client_secret and redirect_url are verified before tokens are exchanged.
There you go. Next time you are asked this question, you know how to answer.