OAuth (Open Authorisation) is a protocol that lets you, as an internet user, permit application A to read/write data in application B, all without application A knowing about your credentials into application A.

There are versions of OAuth: OAuth 1.0 and OAuth 2.0. OAuth 2.0 is an improved protocol that’s more widespread and less complex.

How OAuth Works

There are 4 actors in the OAuth sequence.

  • Resource Owner (you, the user)
  • Client (Application A)
  • Resource Server (Application B)
  • Authorisation Server (which may be part of Application B or an external server not managed by Application B) (source)

Suppose here we have a client, Foo, that wants to access your Google Photos.

  1. You, the user, click ‘Sign In with Google’.
  2. Foo frontend sends the user to an endpoint on Google’s authorisation server. The authorisation server opens the consent screen.
  3. After the consent screen is accepted, Google redirects the user to the authorised redirect URI with an authorisation code that Foo server now has.
  4. Foo server sends the authorisation code plus the client ID and client secret to Google’s Authorisation servers and gets back an access token and refresh token which Foo server is responsible for storing securely. The refresh token is used to obtain a new access token after it expires without user interaction.
  5. Now Foo server can use the obtained access token in its requests to the Google Photos API.

OAuth Client ID Creation

Suppose we want to create a Google OAuth Client ID. See the Setting up OAuth 2.0 guide. OAuth Client ID — an ID that the authorisation server uses to identify your client application

  • This is publicly known and safe to expose.
  • Typically, this ID remains constant for the lifetime of the client application.

OAuth Client Secret — a long, random-looking string generated by the authorisation server.

  • This must be kept private and is only meant to be known by the authorisation server and the client application.
  • Can be regenerated for better security.

Think of the Client ID as the username and the Client Secret as the password. The Client ID + Client Secret are the credentials needed for an authorisation server to grant the client application an access token, which is used to access the resource server. If that’s a confusing sentence, re-read how OAuth works.

Authorised JavaScript Origin — the domain that the JavaScript client application is hosted on. E.g. https://foo.com or http://localhost or http://localhost:3000 if your JavaScript client is running on a port that’s not 80.

  • In short, an authorised javascript origin is a domain (like localhost or foo.com) that is permitted to talk to Google’s authorisation servers and begin the OAuth flow.

Authorised redirect URI — the URL that Google redirects the user to after they have accepted/denied the consent screen.

  • You set what the redirect URI is when you are creating the OAuth client ID.

Consent Screen — a webpage that you get redirected to by the authorisation server. When setting up an OAuth Client ID for the first time, you need to set up a consent screen.

Oh my god. I wasted hours on this. Make sure that the redirect URI you set in Google’s API console is the exact same as the one your app actually uses. In my case, there was a trailing forward slash, so I had http://localhost:5000 instead of http://localhost:5000/. Yup this makes the difference.