Overview

In the previous article, we’ve covered OAuth2 stateful (session-based) authentication via Google and Facebook.
Stateful authentication stores authentication sessions in some internal storage (in-memory, database, Redis, etc.) and returns a session identifier to a user.
In this tutorial, we’re going to cover stateless OAuth2 Google authentication when after a successful authentication a user receives an independent token (JWT in 99% of cases) with all required information in it. Both types of authentication have their own advantages and disadvantages. Stateless authentication is widely used for SPA applications and mobile clients.

Stateless OAuth2 Google authentication basics

Before diving into implementation details, let’s learn how the stateless OAuth2 Google authentication process works in general.

Let’s say we have a client application (SPA on Angular/React/Vue/etc.) which needs to access server API. In order to use the API, the client has to be authenticated. The server verifies whether an incoming request is authenticated or not based on the presence of a valid token in a request header (usually Authorization header is used).

When a client app needs to get authenticated, it sends a request to a server endpoint specifying a redirect URL of a client app (used when all the authentication was finished).

The server saves an authentication request and redirects the client to a Google authentication page specifying a redirect URL that leads to the server back. The authentication request that came to Google also specifies:

• state – identifies an authentication request saved on the server
• a response type (code type is used to receive a code to be exchanged for access and refresh token)
• client id (stored on server side)
• scope (what access we request)

Google adds the requested code (along with others) to query parameters of a redirect URL and redirects the client to the server.

The server uses the code to exchange it for access and refresh token. Access token is used to get access to a user information stored in Google profile. It can expire. Refresh token is used to update the access token.

When the server got the access token, it requests all the needed Google profile information, adds additional custom fields and packs it all into a JWT token. This token is added as a query parameter to a redirect URL specified in the initial client request.

When a client is redirected to a resulting URL, it has an independent token which contains everything what’s needed. Every further requests to a server API will contain this token sent in Authorization header with a value “Bearer <token>”. That’s it.

To visualize the described authentication process, let’s have a look at the following sequence diagram:

Implementation

Since the topic is not trivial and a final solution has resulted in many classes, we’ll not paste the code portions here, but include a link to a GitHub repository and a video with a detailed explanatioon.

GitHub Repo

References

The following article has been used as a base source – Spring Boot OAuth2 Social Login with Google, Facebook, and Github.