Create a Flask Application With Google Login

You’ve probably seen the option for Google Login on various websites. Some sites also have more options like Facebook Login or GitHub Login. All these options allow users to utilize existing accounts to use a new service.

In this article, you’ll work through the creation of a Flask web application. Your application will allow a user to log in using their Google identity instead of creating a new account. There are tons of benefits with this method of user management. It’s going to be safer and simpler than managing the traditional username and password combinations.

This article will be more straightforward if you already understand the basics of Python. It would also help to know a bit about web frameworks and HTTP requests, but that’s not strictly necessary.

By the end of this article, you’ll be able to:

• Create a Flask web application that lets users log in with Google
• Create client credentials to interact with Google
• Use Flask-Login for user session management in a Flask application
• Better understand OAuth 2 and OpenID Connect (OIDC)

You can click the box below to get the code for the application you’ll make in this article:

Why Use Google Login for Your Users?

You may want individual users to have profiles. Or perhaps you want to provide features to only certain users. In any case, you’ll need to know who’s interacting with your application. In other words, you’ll need to authenticate users and identify them in some unique way.

The traditional solution is to use a unique username and a secret password. Your application would store that information and ask for it when needed. However, there are a few downsides to that solution:

• You have to securely manage the passwords.
• You have to implement any account-related functionality:
  • Two-factor authentication
  • Password reset
• You have to protect against malicious login attempts.
• Your users have to remember yet another username and password.

By using Google login for your users, you push all that responsibility to them. Your application waits for the user to go through authentication. Google then tells your application about that user. At that point, you can effectively log them into your application.

You don’t have to store any passwords, and Google handles all the security.

How Applications Use Google Login

There are two very popular and important specifications called OAuth 2 and OpenID Connect (OIDC). OIDC is built on top of OAuth 2, adding a few new ideas and concepts.

These specifications define how a third-party application can obtain information from another service. This usually involves obtaining consent from a user. To unpack this a bit, let’s look at how this applies to the application you’re about to build.

You’re about to write a third-party application, and it will let a user use a Google Login button to log in. To do that, Google needs to know about your application. Luckily, you can register your application as a client to Google.

Once a user comes to your application and presses the Google Login button, you can send them to Google. From there, Google needs to make sure that the user consents to pass along their email and other information to your application. Should the user consent, Google sends back some information to your application. You then store that information and can reference it later, effectively logging the user in.

OpenID Connect Details

To request information on behalf of a user, you must become a client to the authentication server, also known as the provider. The first thing you’ll realize if you dig into these specifications is that there are a lot of overlapping terms and concepts.

So as a third-party application (also known as a client), you want to get info from the provider on the user’s behalf. There are a series of steps that enable that to happen, and those steps must happen in a specific order. That’s why you’ll sometimes hear OAuth 2 and OpenID Connect referred to as a handshake, flow, or dance.

Those steps are, broadly:

1. You register a third-party application as a client to the provider:
   • You receive unique client credentials from the provider.
   • You’ll use these client credentials to authenticate (prove who you are) to the provider later on.
2. The client sends a request to the provider’s authorization URL
3. The provider asks the user to authenticate (prove who they are)
4. The provider asks the user to consent to the client acting on their behalf:
   • Usually this includes limited access, and it’s made clear to the user what the client is asking for.
   • This is like when you have to approve an app on your phone to have access to location or contacts.
5. The provider sends the client a unique authorization code.
6. The client sends the authorization code back to the Provider’s token URL.
7. The provider sends the client tokens to use with other provider URLs on behalf of the user.

Those steps include both of the standards mentioned so far. OpenID Connect (OIDC) is built on top of OAuth 2, adding a few additional features and requirements, mostly involving the process of authentication. Other than the authentication mentioned in the flow above, the important OIDC concepts for your application are the provider configuration and userinfo endpoint.