Ctrl

Disclaimer: views, thoughts, and opinions expressed here are solely my own, and do not relate with or reflect the views, opinions, policies, or position of my employer.

In August 5th 2021 Google announced that they are discontinuing the "Google Sign-In" Javascript library. The replacement is the new "Sign in with Google" client library, part of Google's new identity services.

So how does "Sign in with Google" work?

Contents:

TL;DR

"Sign in with Google" is an implementation of the OpenID Connect (OIDC) technology. OpenID Connect is an authN layer built on top of the OAuth 2.0 authZ framework. In fact, the OIDC protocol explained in this post is called the "Implicit Flow with Form Post".

If the previous paragraph was Greek to you, keep reading :)

Intro

First of all, you can see "Sign in with Google" in action in my "Hello Google Authenticatoin" web application. Go ahead and give it a try!

In this blog post, I'm explaining how "Sign in with Google" works to my younger under-grad self, at the time where I knew only the basics about how web applications work.

To make things easier to grasp, I'm following a top-down approach, talking about big ideas first, before diving into the details. I think that the higher-level concepts should be already familiar, laying the foundation for finer-grained information explained later, painting an overall picture that is meaningful.

So let's get started! Basic question: Why does "Sign in with Google" even exist?

Why does it exist?

As a user, "Sign in with Google" allows you to authenticate easily and securely to web applications using your Google identity.

As a web application developer, "Sign in with Google" relieves you from the hustle of storing and managing user credentials making your web app more secure.

Simply put, "Sign in with Google" allows the user to log in to web applications (read websites) using their existing Google account, without a need to create a new account specific for this web app. This is done easily with an one- or two- click process, and it's more secure than using usernames and passwords.

But what does "more secure" even mean, I hear you mumble.

Is it any good?

In information security, it's hard to make broad statements about something just being better or safer than the other thing and expect to be taken seriously.

So here are some pros and cons about "Sign in with Google".

Pros:

• The user doesn't have to create, remember, and manage a username and a password for every web application that they use.
• The developer doesn't have to securely manage and store usernames and passwords and take on the heavy responsibility of being a good steward of user credentials.
• The user can rest assured that poorly designed or even compromised web apps will not leak their credentials (because they don't have any).
• The user can re-use a single web identity across multiple web apps.
• The authentication process is fast.
• The authentication process can benefit from extra security measures such as MFA and OTP which an identity provider (see below) like Google may offer but the web app may not.
• Web identity theft is harder to occur, assuming that your Google account is properly secured.

Cons:

• The overall scenario depends on a third-party identity provider that exists and is trusted by both the user and the developer.
• The user needs an account on the identity provider, in this example Google.
• The developer needs to setup the integration with the identity provider, and have a dependency on their identity system.
• If the user's Google account is compromised by an attacker, they would be able to impersonate the user to many different web apps.

So to recap, for users (not you my dear reader, right?) who re-use the same username and password across multiple web apps and never change those passwords, it may be safer to move to "Sign in with Google".

For developers who don't know how to- or don't have the capacity to- keep up with security's best practices (I, for one, accept the fact that security is hard) it may be safer to move to "Sign in with Google".

So should people use it? If you ask me, my answer is definitely yes for small to medium web apps that are not, say, in the banking or medical business.

Building a new toy web app to host picture of cats? Use "Sign in with Google". Less work for you to do, better experience for your users.

Identity

Now maybe it's a good time to talk a bit about identity. Truth is, identity is a huge topic on its own, so I won't try to cover everything here.

Take a moment to visualize a web application sitting somewhere at the vast landscape of the world wide web, reachable by virtually everyone. Web applications are computer programs that need to deal with multiple users. How can computers know who the user is?

Identities are data structures -- sequences of zeros and ones -- that represent humans or roles. Humans use identities to let programs know who the user is.

For example, consider a home computer running Microsoft Windows XP. An operating system, similar to web applications, is another example of computer programs used by different users.

So if we have two humans, Jack and Jill, we can imagine the following three identities known to the Windows XP operating system:

• Jack, as a user
• Jill, as a user
• Jill, as the system administrator

Depending on the identity of the logged in user, the operating system will display different files, programs, and controls, to Jack, to Jill, and to Jill when she's using her administrator account.

This simple example demonstrates that identities do not need to map 1-to-1 to humans. This is why we said earlier that identities represent humans or roles.

Identity: first party VS third party

Going back to web applications, typically, users create and use identities in web applications in order to consume content specifically tailored to them, and/or to generate new content and associate their creations with themselves. For the former example think about viewing your personalized movie suggestions on Netflix, while for the latter think about posting your own thoughts on Twitter.

Similarly to how Jill's administrator identity is only valid for their home computer running Windows XP, the identities used for the web application are valid only for this specific web application. We call these identities first-party. It means that they are created, managed, and valid, only within the boundaries of the web application. The identities simply do not exist outside of the web app.

In addition to first-party identities, there are also third-party identities. These identities are provided and managed by external systems, often called identity providers. The validity of those identities usually spans multiple systems. As explained previously in the "Is it any good?" section, there are good reasons for centrally managing identities and using the same identity across multiple web applications.

Google is an identity provider that can offer identities to be used by many different web apps when using "Sign in with Google".

Authentication - authN

We said previously that an identity lets the web app know who the user is.

But simply telling the web app that you want to use an identity should not be enough. Instead, you must prove to the web app that you are in position to use the identity that you claim.

The process of proving your identity to a web application is called authentication (or shortly authN).

Every time you log in to a web app with your username and password you are essentially authenticating. You prove to the web app that you should be allowed to assume your identity (read: account) and continue using the web application as a logged in user. Why? Because the underlying assumption is that only you know the username and password combination which protects the said identity.

Usernames and passwords are a very common way to secure first-party identities in web apps. But most often, protection in web apps stops there, because the focus of the web developers is in their business domain.

On the other hand, third-party identity providers like Google usually take account protection a few steps further, because their main focus is in their user accounts.

Authorization - authZ

Now that we explained authentication, it's a good time to also talk about authorization (or shortly authZ).

Authentication and Authorization may sound very similar, but they actually refer to very different concepts.

Authentication is when a program checks whether a user is allowed to log in.

Authorization is when a program checks whether a user is allowed to perform a specific operation within the web application.

It's safe to imagine that after a user requests to execute an operation, and before the operation is actually performed, the web application checks whether the user is allowed to perform that operation.

Let's use IMDB as an hypothetical example:

• Any internet user can browse the top 250 movies of all time. Authentication: not needed. Authorized operations: list top movies.
• IMDB users can vote and comment on their favorite movies. Authentication: needed, as users. Authorized operations: vote movie, comment movie, edit their profile, ...
• But only administrators can delete inappropriate comments. Authentication: needed, as administrators. Authorized operations: delete movie comment, ban user, ...

A random internet user is not authorized to vote or comment or do anything other than browsing movies and their ratings. Similarly, authenticated IMDB users are authorized to vote and comment, but they are not authorized, say, to delete other users' comments. Administrators, when authenticated, have authorization to manage the platform and delete comments or ban other users.

The take-away is that performing a non-trivial operation in a web application requires two steps. The first step is authentication and the second step is authorization. The user must first prove their identity, and then their identity is checked whether it conveys enough permissions to perform the requested operation.

Tying all the pieces together

"Sign in with Google" provides an easier/safer way to authenticate yourself to a web application. Instead of using a username and a password to log in as a local first-party identity, you assume a third-party identity provided by Google.

As long as the web application correctly supports the "Sign in with Google" process, your Google identity should allow to you log in and use the web application just as if you were using a first-party identity.

Part 1 recap

In this part we saw why "Sign in with Google" exists and what problem it tries to solve.

We listed some pros and cons on this approach, and touched on the fundamental topics of identity, authentication, and authorization.

In the next part we'll dive deeper on the authentication process, before explaining the "Sign in with Google" technology.