How to implement Google authentication in a SvelteKit application with Lucia

Authentication might be one of the most common features of a web application. And Google OAuth is a popular way of achieving that feature. It's also a very practical way to  authenticate users on your website .

In this article, we'll explore how to implement Google authentication in a SvelteKit application using Lucia Auth.

Understanding the OAuth Protocol and Flow

Before diving into the implementation, it's important to understand what OAuth is and how it works. OAuth (Open Authorization) is a protocol that allows an application to request access to a user's protected resources without directly handling their credentials (username and password). It's commonly used to grant third-party applications limited access to user accounts on services like Google, Facebook, and Twitter.

How OAuth Works

OAuth operates through a series of steps known as the OAuth flow. Here's a breakdown of the typical OAuth 2.0 flow:

1. User Initiates Authentication : The user attempts to log in to your application using a third-party service, such as Google. They click on a “Login with Google” button.

2. Redirect to Authorization Server : Your application redirects the user to the Google Authorization Server with a request for access. This request includes the application’s client ID, the scope of access being requested (e.g., user profile info), and a redirect URI to send the user back to after authorization.

3. User Grants Permission : The Google Authorization Server presents a consent screen to the user, asking if they are willing to grant your application the requested access. The user must approve this request to proceed.

4. Authorization Code Issued : Once the user consents, the Google Authorization Server redirects the user back to your application with an authorization code. This code is short-lived and cannot be used on its own to access resources.

5. Exchange Authorization Code for Access Token : Your application sends the authorization code to the Google Authorization Server, along with the client secret, to request an access token. The client secret is a confidential key issued to your application when you registered it with Google.

6. Access Token Received : If the authorization code is valid and the request is authenticated, Google returns an access token to your application. This token allows your application to access the user’s resources on their behalf.

7. Access Protected Resources : Your application uses the access token to make API requests to Google’s resource server. The access token must be included in the authorization header of these requests.

8. Refresh Token (Optional) : In addition to the access token, your application might receive a refresh token. The refresh token can be used to obtain a new access token without requiring the user to re-authenticate when the original token expires.

Now that we have a good idea of how OAuth works, let's move on to implementing Google authentication in a SvelteKit application using Lucia Auth.

Lucia

Lucia  is an open-source, lightweight and highly customizable session-based authentication library for TypeScript applications. The library provides a set of primitives and utilities for building secure and scalable authentication systems. It's framework and database agnostic, and provides providers and adapters for popular databases like PostgreSQL, MySQL, and SQLite.

Setting up the SvelteKit project

Let's start by creating a new SvelteKit project with TypeScript and ESLint. We will also use the SvelteKit node adapter.

Loading code block

Let's now update the  svelte.config.js  file to use the node adapter.

Loading code block

Let's also install Tailwind CSS to make styling a bit easier and faster.

Loading code block

Setting up the database

No matter the authentication method you choose, or the provider you want to use, you might need a database to store user information, or authentication metadata from the provider.

With Lucia, we'll need to store the user's email address, as well as the session information.

I like using SQLite in my projects because it's a lightweight and easy-to-use database, and for most use cases, it's very well capable and sufficient.

We will also need something to interact with the database, preferably in a type safe way.  Drizzle ORM  has been my go-to for this, and it's a great choice for TypeScript projects.

If you want a full guide on how to set up a SQLite database with Drizzle, refer to this article .

The steps are pretty straightforward:

• We install the necessary dependencies

• We create a client for Drizzle that connects to the database

• We create a config file to tell Drizzle where is the database schema located, and where to run and store migrations

• We create a database schema

• And we apply the schema to the database

Loading code block

Loading code block

Loading code block

Now, the schema file:

Loading code block

Let's look at this schema in more detail.

For Lucia to work, we need a  users  and a  sessions  table.

Note : You can name these tables whatever you want, as long as you specify to Lucia those names. We'll see how to do that in a bit.

The required column for the  users  table is the  id  column. By default, Lucia expects this to be a  text  (string) column. But this is customizable, and  you can specify a different type for this column .

The  sessions  table needs to have an  id  (must be of type  text ),  expires_at  and a  user_id  column that references the  id  column of the  users  table.

For convenience and good practice, we'll also add timestamps to all the tables.

Also notice that I'm using the  $defaultFn  method from Drizzle to set default values for the  created_at ,  updated_at  and  id  columns. These default values will be set only if they are not provided when inserting a record.

The  generateId()  function is a simple function based on the  oslo/crypto  package. Here's its implementation:

Loading code block

Once you apply this schema to your database ( pnpm push:db ), you should be able to see your database being created at  src/lib/server/db/sqlite.db .

Again, take a look at this  blog post  for more information on how to set up a SQLite database with Drizzle.

CRUD operations

Let's create a few CRUD functions for our user's table.

Loading code block

Google Cloud project

To use Google OAuth, we need to create a Google Cloud project. This project will have necessary information to authenticate users with Google.

You can do this by going to the  Google Cloud Console  and creating a new project.

The OAuth consent screen

This is where you will add the information about your application and the scopes you want to request from the user. You can access the consent screen page by going to  https://console.cloud.google.com/apis/credentials/consent?project={project-id} . Make sure to add the following scopes for your application:

• openid

• userinfo.email:  https://www.googleapis.com/auth/userinfo.email

• userinfo.profile:  https://www.googleapis.com/auth/userinfo.profile

And also, add a test email address in case you would like to test the login process with an email address besides the one used on your Google Cloud account.

OAuth client ID

The OAuth client ID tells Google which URLs are allowed to make requests to Google servers for verifying the user's identity. You can access the client ID page by going to  https://console.cloud.google.com/apis/credentials/oauthclient?project={project-id} .

The “Authorized JavaScript origins” should be set to the URLs where your application will be accessible. In local, for SvelteKit, this is  http://localhost:5173 . You can also add other origins, like the production URL of your application or staging or testing URLs.

The “Authorized redirect URIs” should be set to the URLs where your application will be redirected after the user has authorized your application.

In local, for SvelteKit, we will use  http://localhost:5173/login/google/callback .

Once you have created your client ID, you will see a modal with the client ID and client secret. You will need to copy the client ID and client secret and update the values in the .env file.

Loading code block

Setting up Lucia

Now that we have our database set up, we can start setting up Lucia.

Here again, we need to install a few dependencies.

Loading code block

The  lucia  package contains the core of Lucia, and  @lucia-auth/adapter-sqlite  is used to connect Lucia to a SQLite database.

Let's create a few files to get Lucia up and running.

Loading code block

Here is what's happening here.

First, we create the adapter that Lucia will use to interact with the database. We're using the  BetterSqlite3Adapter  which uses  better-sqlite3  under the hood. In the adapter, we specify the table names for the users and sessions.

Then, we create the Lucia instance. We pass the adapter to the constructor, and we also specify the session cookie attributes. We set the  secure  attribute to  true  in production environments, and to  false  in development environments.

That's mainly what's needed to have Lucia working.

A few more details.

When Lucia creates and validate a session, it returns session data and data about the authenticated user. By default, only the minimum required data is returned. We can customize this behavior by implementing the  getSessionAttributes  and  getUserAttributes  methods with additional data.

We also declare a “lucia” module for TypeScript to be aware of the Lucia instance and its types.

In addition to the  lucia.ts  file, we will also have a second file with the Google OAuth configuration.

Loading code block

We use  arctic , a TypeScript library that provides OAuth 2.0 and OpenID Connect clients for major providers.

Implementing the login flow

Let's start with the entry point, the login page.

Loading code block

When the users click on the “Login” button, the  GET  request will be sent to the  /login/google  route. This route contains a SvelteKit server endpoint, that will then redirect the user to the Google OAuth login page.

Loading code block

Here, we are basically storing a state and a code verifier in the cookies. These will be needed later in the callback to make sure that those identifiers from the cookies match the ones from the OAuth response.

The callback endpoint

There are many things that need to be done in the callback endpoint.

First, we need to get the state from the cookies and check if it matches the one we sent to the Google OAuth server.

We also want to make sure that the code query parameter is actually present in the URL.

And return an error response if that's not the case.

Loading code block

Next, we will use the codeVerifier (saved earlier in the cookies) and the code query parameter to get access and refresh tokens from the Google OAuth server. These credentials are required by Google to make requests on the user's behalf.

These tokens will be used to make a call to the Google API at  https://openidconnect.googleapis.com/v1/userinfo  to get the user's profile information.

Side note, in this case, login acts both as a login and a registration. If the user data (retrieved from the Google API) doesn't exist in our database, we create a new user and a new session.

Otherwise, we update the user data and the session data.

Here's the whole endpoint code with that logic:

Loading code block

When everything runs without errors, we will redirect the user to the  /profile  page, which will be protected and only be accessible to authenticated users.

Hooks

You might think that, at this point, we have a fully functional authentication system. But we still have some work to do. We want, on every request to our application, to check if the user is authenticated. And whether the user is authenticated or not, we want to return a  sessions  and  users  object.

These two objects will carry information about the current user and be available across the entire application.

To achieve that, we'll use hooks, and specifically the  handle  hook. The handle hook in SvelteKit is a function that runs before and after every request made by the application. It's used to handle things like authentication, authorization and more.

Let's create this hook in the  src/hooks.server.ts  file.

Loading code block

Some explanations. In the callback logic before, we've created a session and a session cookie with  lucia.createSession()  and  lucia.createSessionCookie()  if the login has been successful.

Now, in our handle hooks (that, remember, will run before and after every request, whether the user is authenticated or not), we'll check if the session cookie exists in the request. If that's the case, we'll check if it's valid.

In case the session is valid, we return a user and a session objects inside SvelteKit locals. If the session is not valid, we just set blank session cookie.

Note : We can (should) add some type safety to the  locals  so that TypeScript is aware of the objects we're returning.

Loading code block

The profile route

The last thing we need to do is to create a route that will show the user's profile.

Let's start with the load function in  src/routes/profile/+page.server.ts .

Loading code block

Because  /profile  is a protected route, we need to check if the user is authenticated. If the user is not authenticated, we redirect the user to the login page.

We also get and return the user profile data (from the  users  table).

And let's display these data on the page.

Loading code block

Wrapping up

By following this guide, you now have a SvelteKit application with Google authentication using Lucia Auth.

This setup provides a secure and convenient way for users to log in with their Google accounts, leveraging the OAuth protocol and a lightweight, customizable authentication library.

This implementation covers the essentials: configuring a Google Cloud project, setting up a SQLite database with Drizzle ORM, and integrating Google OAuth into your SvelteKit app.

With these steps, your application is equipped with a robust authentication system that can be further customized to fit your needs.

Happy coding!