DEV Community: Aakash Goplani

Comprehensive Guide to SvelteKitAuth: Secure Authentication for SvelteKit Apps

Aakash Goplani — Sun, 14 Jul 2024 17:02:00 +0000

I've been working on an exciting series about authentication in SvelteKit using SvelteKitAuth. This comprehensive guide covers everything from the basics of SvelteKitAuth and its configuration to how it operates under the hood. You'll find detailed steps for integrating built-in providers like Auth0, as well as custom providers. The series also delves into sign-in and sign-out flows, session management, and advanced configurations such as callbacks, events, and custom pages. My goal is to simplify the authentication process in SvelteKit applications, making it both secure and efficient. Here's what you'll learn:

Chapter 1: Introduction to SvelteKitAuth

SvelteKitAuth is an extension of NextAuth, now part of the Auth.js project, providing robust authentication for SvelteKit applications. It supports OAuth and OpenID Connect with 68+ providers like Google and Facebook, and offers various authentication methods including email/passwordless and username/password. SvelteKitAuth handles the entire authentication flow, from configuration to session management, and can use database sessions or JWT. It also includes built-in security features like CSRF protection and server-only cookies, making it a comprehensive solution for integrating authentication in SvelteKit apps. Get more insights by reading the full blog.

Chapter 1(b): How OAuth Operates: A Simple Breakdown

OAuth is a secure way for websites to share information without giving full access. It involves a user granting permission to a website to access specific information from another account (like Google) without sharing passwords. OAuth with PKCE adds extra security by using a secret code to ensure only the legitimate app can access the information. This process enhances security and convenience for users. Get more insights by reading the full blog.

Chapter 2: Setting Up Auth0 and Adding SvelteKitAuth to Your App

Integrate SvelteKitAuth with SvelteKit using Auth0 by first setting up an Auth0 application. Configure the application with appropriate callback URLs and allowed web origins. Then, choose between using built-in OAuth providers like Auth0 for ease and security or custom OAuth providers for more control and customization. Get more insights by reading the full blog.

Chapter 3: Step-by-Step Guide to Using built-in (Auth0) OAuth provider with SvelteKitAuth

Integrate Auth0 OAuth with SvelteKitAuth by configuring essential properties like id, clientId, clientSecret, and issuer. Place the authentication code in hooks.server.ts to ensure secure access to protected resources. Advanced options like callbacks, logger, and events can enhance the developer experience. Set necessary environment variables for a streamlined authentication process. Get more insights by reading the full blog.

Chapter 4: Step-by-Step Guide to using custom OAuth provider with SvelteKitAuth

Integrating a custom OAuth provider with SvelteKitAuth allows for extensive customization in your authentication mechanism. This guide covers the necessary configurations, including authorization, token, and userinfo properties, to tailor the authentication process to your needs. The article also provides a code snippet for the custom provider and emphasizes the flexibility of including multiple providers in the same configuration. Get more insights by reading the full blog.

Chapter 5: How to Integrate Multiple OAuth Providers in SvelteKitAuth

Integrating multiple OAuth providers in SvelteKitAuth enhances user experience by offering diverse sign-in options like Google, GitHub, and LinkedIn. This flexibility improves user convenience and broadens the potential user base. The article provides a step-by-step guide to configure multiple providers, ensuring a smooth and secure authentication process. Get more insights by reading the full blog.

Chapter 6: Enhancing SvelteKitAuth with Custom Type Additions

Enhancing SvelteKitAuth with custom types involves creating a custom typings file, updating the TypeScript configuration, and restarting your IDE to ensure all necessary types are recognized, reducing errors and improving code quality. Get more insights by reading the full blog.

Chapter 7: Streamlining Client-Side Sign-In and Sign-Out Processes

In this article, we explore how to streamline client-side sign-in and sign-out processes using SvelteKitAuth. We cover the signIn() and signOut() methods from @auth/sveltekit/client, detailing their properties and options for a seamless user experience. The article also provides links to official documentation and a GitHub repository for further reference. Get more insights by reading the full blog.

Chapter 8: Optimizing Server-Side Login and Logout Processes

Optimizing server-side login and logout processes involves using form actions provided by @auth/sveltekit or programmatically handling authentication, especially when using third-party vendors. The sign-in flow includes preparing a payload, making a POST call, and redirecting users, while the sign-out flow requires reloading the page after logging out. Understanding both client-side and server-side authentication ensures robust and flexible mechanisms in applications. Get more insights by reading the full blog.

Chapter 9: User Sign Out: Application vs OAuth Provider

In this article, we discussed the differences between signing out a user from the Application layer and the OAuth layer. We explained how SvelteKitAuth handles user sign-out by clearing the session token and resetting the session, while the OAuth provider's session remains active. We also provided a method to log out users from the OAuth provider's session layer using the OIDC endpoint and emphasized the importance of configuring the Allowed Logout URLs in Auth0 for a secure and seamless user experience. Get more insights by reading the full blog.

Chapter 10: How to Manage Sessions in SvelteKit with SvelteKitAuth

Managing sessions in SvelteKit with SvelteKitAuth involves server-side session management using the auth() method to access user information and session expiration details, and client-side session management using the $page store for component-level and route-level authorization checks. This ensures secure and efficient session handling in SvelteKit applications. Get more insights by reading the full blog.

Chapter 11: How to Implement Refresh Token Rotation in SvelteKitAuth

Implementing refresh token rotation in SvelteKitAuth involves creating an API route to refresh tokens, configuring jwt and session callbacks to handle token rotation, and invoking the refresh process from the client side. This ensures secure and seamless user sessions by automatically updating access_token without requiring user re-authentication. For detailed steps and code, refer to the provided GitHub repository. Get more insights by reading the full blog.

Chapter 12: How to Exchange Data Between Client and Server Using SvelteKitAuth

This article explains how to exchange data between the client and server using SvelteKitAuth. It covers the importance of JWT and session callbacks, and how to synchronize and store sessions effectively. The process involves configuring the jwt and session callbacks, creating an update endpoint, and initiating update requests from the client. Additionally, it discusses how the server can send information back to the client through hydration using server load functions. The article provides a step-by-step guide to ensure seamless data synchronization in SvelteKit applications. Get more insights by reading the full blog.

Chapter 13: Steps to Build Custom Pages and Handle Events in SvelteKitAuth

Steps to build custom pages and handle events in SvelteKitAuth:

Custom Pages: Auth.js allows creating custom authentication pages for sign-in, sign-out, and error handling to match your app's design. Configure these by specifying the path in the SvelteKitAuthConfig object.
Events: Auth.js provides hooks for actions like sign-in, sign-out, and session management. Configure these events to execute custom code for logging, analytics, or other side effects.

Customizing pages and handling events enhances user experience and functionality. For more details, refer to the provided links and GitHub repository. Get more insights by reading the full blog.

Chapter 14: Managing Shared Sessions Across Multiple Applications in SvelteKitAuth

Managing shared sessions across multiple applications in SvelteKitAuth involves configuring session cookies for same-domain apps and using a proxy identity server for cross-domain apps. For same-domain apps, update the cookie's domain property. For different domains, set up a proxy server to handle OAuth callbacks, centralizing authentication and ensuring seamless session sharing. Detailed steps and configurations are provided for both scenarios. Get more insights by reading the full blog.

Chapter 15: Drawbacks of SvelteKitAuth You Should Know

SvelteKitAuth has several drawbacks, including the need for workarounds in complex scenarios, limited updates and focus on Next.js, poor documentation, minimal community support, and subpar developer experience. These issues make it less suitable for enterprise-level applications or projects with intricate authentication requirements. Get more insights by reading the full blog.

Conclusion

In conclusion, SvelteKitAuth offers a comprehensive and robust solution for integrating authentication into SvelteKit applications. With support for a wide range of OAuth and OpenID Connect providers, it simplifies the authentication process while ensuring security through features like CSRF protection and server-only cookies. The guide covers everything from setting up Auth0 and integrating multiple providers to managing sessions and implementing refresh token rotation. Despite some drawbacks, such as limited updates and community support, SvelteKitAuth remains a powerful tool for developers looking to enhance their SvelteKit apps with secure and flexible authentication mechanisms. Here is the link to the GitHub repository with the codebase.

Internationalization in SvelteKit with svelte-i18n, sveltekit-i18n and typesafe-i18n

Aakash Goplani — Wed, 02 Aug 2023 14:55:25 +0000

In this series, I'll be demonstrating internationalization in SvelteKit with three different libraries: svelte-i18n, sveltekit-i18n and typesafe-i18n.

Internationalization in SvelteKit with svelte-i18n

This is the first article of three-part series to demonstrate i18n in SvelteKit. In this article, we will work on integrating svelte-i18n with SvelteKit.

svelte-i18n helps you localize your app using the reactive tools Svelte provides. By using stores to keep track of the current locale, dictionary of messages and format messages, it keeps everything neat, in sync and easy to use on svelte files.

Under the hood, svelte-i18n uses formatjs for localizing messages. It allows svelte-i18n to support the ICU message syntax.

Application Structure

Before we begin, I want to give you a detailed walkthrough of the application that we will be working on. You can find the code in the GitHub repository.

As we can see from the image, this will be a simple single-page application demonstrating i18n features like locale switching, pluralization and formatting.

In the next section, we will work on integrating the svelte-i18n library with SvelteKit.

Integration with SvelteKit

Read the complete integration flow on my blog.

Internationalization in SvelteKit with sveltekit-i18n

This is the second article of three-part series to demonstrate i18n in SvelteKit. In the previous article, we worked our way with svelte-i18n and in this article, we will work on integrating sveltekit-i18n with SvelteKit.

The sveltekit-i18n is a tiny library with no external dependencies, built for Svelte and SvelteKit. Key features include:

SvelteKit ready.
SSR support.
Custom data sources: no matter if you are using local files or remote API to get your translations.
Module-based: your translations are loaded for visited pages only (and only once!)
Component-scoped translations: you can create multiple instances with custom definitions.
Custom modifiers: you can modify the input data the way you need.
TS support.
No external dependencies.

Application Structure

Before we begin, I want to give you a detailed walkthrough of the application that we will be working on. You can find the code in the GitHub repository.

As we can see from the image, this will be a simple single-page application demonstrating i18n features like locale switching, pluralization and formatting.

In the next section, we will work on integrating the sveltekit-i18n library with SvelteKit.

Integration with SvelteKit

Read the complete integration flow on my blog.

Internationalization in SvelteKit with typesafe-i18n

This is the final article of three-part series to demonstrate i18n in SvelteKit. In the previous article, we worked our way with sveltekit-i18n and in this article, we will work on integrating typesafe-i18n with SvelteKit.

The typesafe-i18n is a fully type-safe and lightweight internationalization library for all your TypeScript and JavaScript projects. One thing that makes typesafe-i18n stand out is that it is a generic library and not limited to Svelte, you can use it with any of your JavaScript or TypeScript projects.

This library introduces a full-fledged flow for maintaining localization in your application. The moment you install this library, it generates a specific folder structure encompassing all the i18n-specific files.

Application Structure

Before we begin, I want to give you a detailed walkthrough of the application that we will be working on. You can find the code in the GitHub repository.

As we can see from the image, this will be a simple single-page application demonstrating i18n features like locale switching, pluralization and formatting.

In the next section, we will work on integrating the typesafe-i18n library with SvelteKit.

Integration with SvelteKit

Read the complete integration flow on my

Comparing i18n libraries in SvelteKit: svelte-i18n, sveltekit-i18n and typesafe-i18n

Based on my learnings from localizing applications in SvelteKit with svelte-i18n, sveltekit-i18n and typesafe-i18n, I've come up with advantages and limitations of each of these libraries.

svelte-i18n

Features

It is a simple and minimalistic library that uses formatjs for localizing messages and supports the ICU message syntax.
It offers to load translations in a synchronous as well as asynchronous manner as per requirement.
Provides a decent number of options for formatting and pluralization.

Ease of Use

Since this library uses native Svelte stores for implementing localization, it feels like part of the ecosystem and hence very easy to get started with!
If you have a simple requirement of changing translations based on a given locale with limited formatting, this should be your go-to library.

Size

As of v3.7.0, the size of the svelte-i18n package is 48.3 kB in the minified form and 14.2 kB in minified + gzipped form. (source)

Community Support

It has 29,978 downloads/week as of the time of writing this article.
The only downside is, this library is not actively managed. Several issues are on the rise and resolution is almost zero.

Limitations

There are very less options available for formatting and pluralization.
As mentioned before, the library is not actively managed.

sveltekit-i18n

Features

It is built for SvelteKit and has good SSR support.
We can load translations from API, database and local file system.
The translations are loaded for visited pages only. (and only once!)
Component-scoped translations: you can create multiple instances with custom definitions.
It provides good TS support and has no external dependencies.
Supports ICU syntax + provides a native parsing engine as well.

Ease of Use

It is very easy to use. I found it even easier while working with the ICU parser (instead of the default parser).

Size

As of v2.4.2, the size of the sveltekit-i18n package is 14 kB in the minified form and 4.6 kB in minified + gzipped form. (source)

Community Support

It has 3,052 downloads/week as of the time of writing this article.
Even though the number of downloads is less than the svelte-i18n but good news is that this library is actively maintained.

Limitations

While working with pluralization, understanding the syntax of the default parser could be a bit challenging at the start.

typesafe-i18n

Features

It is a lightweight, easy-to-use syntax and has no external dependencies.
Because of its strong typings, it prevents you from making mistakes (also in plain JavaScript projects).
Unlike the other two libraries, typesafe-i18n can be used with any framework and supports both TypeScript and JavaScript.
Creates boilerplate code for you which ensures the well-structured flow of i18n in your codebase.
Supports plural rules and allows formatting of values e.g. locale-dependent date or number formats.
It also supports switch-case statements e.g. for gender-specific output.
Provides an option for asynchronous loading of locales.
It supports SSR (Server-Side Rendering) and can be used for frontend, backend and API projects.
Import and Export translations from/to files or services.

Ease of Use

It has some initial learning curve but as soon as we become familiar with the typesafe-i18n ecosystem, this library is not only easy to use but super convenient as well!
Personally, this is my go-to library for i18n.

Size

As of v5.26.0, the size of the typesafe-i18n package is 2.8 kB in the minified form and 1.3 kB in minified + gzipped form. (source)

Community Support

It has 13,588 downloads/week as of the time of writing this article.
This library is actively maintained.

Limitations

It has a huge eco-system (generators, detectors, importers, exporters etc.) and hence learning curve is a bit steep.

Avoid shared state on the server in SvelteKit - Be extra cautious when using stores in SSR mode

Aakash Goplani — Sun, 09 Jul 2023 17:39:58 +0000

State management is a crucial part when working with complex web applications. Svelte does provide us with elegant native stores that can be used in such scenarios. However, we must be cautious while using them otherwise our application may result in unwanted behavior and could produce bugs that are difficult to trace and fix!

One such example is using stores in the backend i.e. in the SSR flow. This article will focus on a few edge cases where we must be extremely cautious in the way we use stores or rather state management in general.

What is the problem?

Using stores in the backend (SSR mode) causes data leaks between clients.

But Why?

Servers are stateless i.e. one common space on the server is shared by multiple clients (users). In other words, the state on Server is global by default that will be shared by all of its clients. The servers are often long-lived and shared by multiple users. For that reason, it's important not to store data in shared variables. For example, consider the following scenario:

Multiple users have been logged into the system and they are interacting with a common application server. Now each user interacts with the server, independently, via the browser. A store is contextual to each instance of your app. This essentially means that the state on the client side is always stateful. If we save any store value on the client side for a particular user, it will remain local to that user and will not be shared with other users.

On the other hand, the state of the server is shared with all the users simultaneously and hence if user "A" updates the store value, that will be reflected on user "B" as well, thus leaking data! In addition, when user "A" returns to the site later in the day, the server may have restarted, losing their data. The main thing to understand is that as soon as you create a store, it becomes global server-side in an SSR context (= your store is a singleton in memory server-side, so it is shared by all HTTP requests hitting your server).

How to fix this problem?

Read rest of the article on my blogging site

Migration Guide from Routify to SvelteKit Router

Aakash Goplani — Sat, 10 Jun 2023 20:13:39 +0000

What is the need for migration?

I had a few personal projects created using Svelte which I am now migrating to SvelteKit.
Svelte did not provide any out-of-box navigation mechanism and hence I was forced to look out for third-party libraries.
SvelteKit, on the other hand, has a built-in mechanism for routing and is constantly evolving for good. Since we have a built-in solution available now, it makes sense to adhere to it.

Before we proceed ahead, I want to stress on this point that Routify is an excellent library. I have used that across many personal and professional projects and the experience has been awesome. The only reason I am migrating from Routify to SvelteKit's built-in router is just my personal opinion which is - I installed Routify only because Svelte didn't have any routing mechanism but SvelteKit does.

Does Routify support SvelteKit?

The current version of Routify i.e. v2.18 DOES NOT support SvelteKit.
We will need to upgrade that to v3-next and as the name suggests, that is still in beta state.
Just upgrading the package will not be sufficient, we will need to do a couple of more configurations that are specified in their documentation. I am sure when they release a stable v3 version, they will have a migration guide (from v2 to v3) ready by then.

Process of Migration

Now that we are done with the introduction, let's go through the migration process.

Read rest of the article on my blogging site

Generate Breadcrumb and Navigation in SvelteKit

Aakash Goplani — Sat, 10 Jun 2023 19:43:19 +0000

Liquid syntax error: Unknown tag 'endraw'

SvelteKitAuth with Salesforce OAuth provider

Aakash Goplani — Sun, 04 Jun 2023 11:40:28 +0000

Before we proceed ahead with this article, I would recommend reading my previous blog post which gives a detailed idea of what SvelteKitAuth is, how it works and basic configuration details. In this blog post, we will go through the configuration for the Salesforce OAuth provider.

We will begin this post by installing the required dependencies:

{
  "@auth/core": "latest",
  "@auth/sveltekit": "latest"
}

Once we have the required dependencies installed, we will go through two configurations i.e.,

Configuring using a built-in provider: SvelteKitAuth provides 60+ built-in providers. If our requirement regarding the configuration is straightforward or in other words does not require any customization, we can select this approach.
Configuration using the custom provider: If our requirement needs some tweaks i.e., we have a custom URL setup for fetching tokens or user details, we will select custom providers.

Working with a built-in provider

SvelteKitAuth provides a built-in SalesforceProvider. Let's walk through the required configuration:

import SalesforceProvider from "@auth/core/providers/salesforce";
...
providers: [
  SalesforceProvider({
    clientId: import.meta.env.VITE_CLIENT_ID,
    clientSecret: import.meta.env.VITE_CLIENT_SECRET,
    wellKnown: 'https://my.salesforce.com/.well-known/openid-configuration'
  })
]

With the built-in provider, we need minimal configuration details like clientId, clientSecret and wellKnown. With this minimal configuration, SvelteKitAuth will complete the authentication process and fetch the required tokens and user details as mentioned in wellKnown config file. I have already covered a detailed explanation of these properties in my previous article.

In the next section, we will go through the configuration required to set up a custom provider.

Working with a custom provider

In many scenarios, our organization would have configured dedicated URLs for authorization, token and user information which will not be available in standard wllKnown configuration file, in such scenarios we must use custom providers.

providers: [{
  id: 'salesforce',
  name: 'Salesforce',
  type: 'oidc',
  client: { token_endpoint_auth_method: 'client_secret_post' },
  clientId: import.meta.env.VITE_CLIENT_ID,
  clientSecret: import.meta.env.VITE_CLIENT_SECRET,
  issuer: 'https://my-custom-issuer-url',
  authorization: {
    url: 'https://my-custom-authorization-url',
    params: {
      app: 'application-name',
      scope: 'refresh_token web openid id api',
      response_type: 'code',
      response_mode: 'query',
      redirect_uri: 'https://my-custom-redirect-url'
    }
  },
  token: 'https://my-custom-token-url',
  userinfo: 'https://my-custom-user-information-url',
  checks: ['pkce']
}]

I have already covered a detailed explanation of every property that is used within the custom provider configuration in my previous article, in this blog post, I'll cover a few important configurations that are required specifically for the Salesforce custom provider.

For the Salesforce custom provider, we have to set the type property to oidc. For the built-in provider, it is set to oauth.
Next, we have to specify the client token endpoint authentication method which is generally "client_secret_post". This particular configuration is subjective and may or may-not-be required in your use case.
Finally, the last required property here is checks which are set to pkce.

Wrapping Up

Now that we have our providers configuration ready, we can put all the required configurations together in src/hooks.server.ts file.

import { SvelteKitAuth } from '@auth/sveltekit';
import type { Handle } from '@sveltejs/kit';

const configuration: SvelteKitAuthConfig = {
  providers: [...],
  debug: import.meta.env.VITE_VERCEL_ENV !== 'production',
  secret: import.meta.env.VITE_VERCEL_SECRET,
  session: {...},
  callbacks: {...},
  logger: {...},
  events: {
    async signOut(message) {
      // revoke token
      const accessToken = message.token.access_token;
      await fetch(`https://revoke-token-url?token=${accessToken}`, {
        method: 'POST'
      })
    }
  }
};

export const handle = SvelteKitAuth(configuration) satisfies Handle;

One important point to highlight is revoking the access token as soon as the user logs out. Salesforce by default does not revoke the token, it is our responsibility as a developer to trigger the event (via POST request) and let Salesforce know that the user has logged out and we should revoke the access token.

For the explanation on the rest of the above-mentioned properties and a few of the other important details like callback URL, redirect URL, sign-in, sign-out and managing session all of which I have covered in detail in my previous article.

SvelteKit Authentication using SvelteKitAuth and OAuth providers: A Comprehensive Guide

Aakash Goplani — Sun, 04 Jun 2023 11:35:52 +0000

NOTE: The contents of this article are now outdated. Please refer the updated content here: Authentication in SvelteKit using SvelteKitAuth

There are multiple ways in which we can authenticate a user over the web, few of them are: matching user credentials in the database, delegating responsibility to an external OAuth provider etc. We can extend those similar concepts in SvelteKit too and implement authentication.

SvelteKit does not provide out-of-box authentication. We can extend the means that we discussed above and implement authentication in SvelteKit. This guide will focus on implementing authentication in SvelteKit using SvelteKitAuth and OAuth providers. After reading this guide, you'll have a decent understanding of implementing authentication mechanisms in SvelteKit.

What is SvelteKitAuth?

SvelteKitAuth is part of the Auth.js project - Authentication for Web which is an open-source library that is easy to use.
SvelteKitAuth is an extension of NextAuth - a popular authentication framework from the Next / React world. NextAuth is now getting a major overhaul and is now becoming Auth.js
It can be used with any OAuth2 or OpenID Connect provider and has built-in support for 68+ popular services like Google, Facebook, Auth0, Apple etc.
Apart from OAuth authentication, it has built-in support for authentication using email/passwordless/magic link/username/password.
We can configure SvelteKitAuth to use database sessions (MySQL, Postgres, MSSQL, MongoDB etc.) or JWT.
It comes with a built-in security mechanism having features like Signed, prefixed, server-only cookies, has built-in CSRF protection & doesn't rely on client-side JavaScript.

Why choose SvelteKitAuth?

Although there are other options available as well, the reason I choose SvelteKitAuth is that it supports OAuth 1.0, 1.0A, 2.0 and OpenID Connect and has built-in support for the most popular sign-in services like Google, GitHub, Auth0, Salesforce etc. It also supports multiple popular database adapters like MySQL, Postgres, MSSQL, MongoDB etc. Apart from that it provides a mechanism to create a custom OAuth provider and custom database adapter as well.

Another reason for going ahead with SvelteKitAuth is it has bigger community support and is backed by Vercel which makes it runtime agnostic, runs anywhere & supports Vercel Edge Functions, Node.js, and Serverless.

How does SvelteKitAuth work under the hood?

To understand how SvelteKitAuth works under the hood, let's explore its internal architecture and the steps involved in the authentication flow.

Configuration: When setting up SvelteKitAuth, you define a configuration file that specifies authentication providers, such as Google, GitHub, or a custom provider. The configuration also includes settings like secret keys, session storage options, and callback URLs.
Authentication Providers: SvelteKitAuth supports multiple authentication providers, and you can choose the ones you want to enable. Each provider has its configuration options, such as client ID, client secret, scopes, and authorization URLs.
Client-Side Flow: When a user initiates the authentication process, SvelteKitAuth handles the flow by redirecting them to the respective authentication provider's login page. This typically involves generating a state and storing it in a server-side session to prevent CSRF attacks.
Callback URL: After successful authentication with the provider, the user is redirected back to a callback URL specified in the SvelteKitAuth configuration. This URL is typically an API route that SvelteKitAuth exposes.
Server-Side Flow: SvelteKitAuth receives the callback request on the specified API route. It validates the received data, including the state parameter, to ensure it matches the stored session state. This step prevents CSRF attacks.
Token Exchange: SvelteKitAuth then exchanges the authorization code received from the authentication provider with an access token. This token allows SvelteKitAuth to make authenticated API requests on behalf of the user.
User Information: With the access token, SvelteKitAuth retrieves the user's profile information from the authentication provider's API. It can fetch details like name, email, profile picture, or any other data that the provider makes available.
Session Management: SvelteKitAuth creates a session for the authenticated user, typically using a secure HTTP-only cookie or a JWT (JSON Web Token). This session contains the user's data and is used for subsequent authenticated requests.
Persistent Sessions: SvelteKitAuth can optionally store session information in a database or other storage mechanisms. This allows users to remain logged in even if the server restarts or the user refreshes the page.
Hooks and Events: SvelteKitAuth provides various hooks and events that you can use to customize the authentication flow, add additional functionality, or integrate with external systems. Examples include the $page.data.session for accessing the session data in components and event hooks like signIn or signOut for performing actions on authentication events.

Overall, SvelteKitAuth abstracts away the complexities of authentication and provides a unified API for integrating with multiple authentication providers. It handles the authentication flow, token exchange, and session management, allowing developers to focus on building their applications without getting caught up in the intricacies of authentication protocols.

How does OAuth work?

As I mentioned earlier that this guide will focus on implementing authentication in SvelteKit using SvelteKitAuth and OAuth providers, we must know how OAuth works.

Auth.js has given a detailed explanation on this topic and I will be quoting that from their site as is. Without going into too much detail, the OAuth flow generally has 6 parts:

The application requests authorization to access service resources from the user.
If the user authorized the request, the application receives an authorization grant.
The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant.
If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete.
The application requests the resource from the resource server (API) and presents the access token for authentication.
If the access token is valid, the resource server (API) serves the resource to the application.

For more details, check out Aaron Parecki's blog post - OAuth2 Simplified or Postman's blog post - OAuth 2.0: Implicit Flow is Dead, Try PKCE Instead.

Configuring SvelteKitAuth with Auth0

For more details, please read rest of article on my blog

State Management with Custom Svelte Store Wrapper

Aakash Goplani — Sun, 05 Feb 2023 03:41:46 +0000

A custom store is an object that provides, at the minimum, the same functionality as any one of the native stores (readable or writable), and that can also provide additional functionality geared more toward domain-specific logic. When this object contains a “properly implemented” subscribe method, the object fulfills the store contract. This allows the object to be treated as a store. Its value becomes reactive, and the store can be referenced with the $ auto-subscription prefix.

Why do we need Custom Store?

It is considered a good pattern (though quite opinionated) that a Component should NOT mutate the state of data. Instead, it should dispatch the action to some middleware (like redux) and that in turn should update the state of data. It encourages state management in one place with components sending messages (actions) about what the user did instead of how the state should update.

Custom Store in Action

import { writable } from 'svelte/store';
import reduxify from './reduxify';

export function configureStore<T>(initialState: T, debugKey = '') {
  const { subscribe, set: _set, update: _update } = writable<T>(initialState);

  const actions = {
    set: (value: T) => {
      _set(value);
    },
    update: (callback: (param: T) => T) => {
      _update(callback);
    },
  };

  const returnValue = {
    subscribe,
    ...actions,
  };

  return debugKey ? reduxify(returnValue) : returnValue;
}

As the wrapper exposes set and update actions that have the same name as the methods exposed by the writable store, it becomes easy for a developer to use it without having to learn any new thing.
This wrapper follows the pattern that we have been discussing throughout – components will not directly mutate the state of data, they will only trigger actions (set and update as exposed by wrapper) which in turn will mutate the state of data.

How to use this wrapper

Changes involved will be minimal as components will use the same syntax as before, only utilities defining stores must be updated.

This is how we have been using stores traditionally for managing states:

// 1. Define store in (say) store.ts file
import { writable } from 'svelte/store';
export const someStore = writable('hello');

// 2. Use them in components
import { someStore } from './store';
someStore.set('hi');
someStore.update((currentState: string) =>  currentState + ' world!');

This is how we will be using stores with wrapper:

// 1. Define store in (say) store.ts file but this time,
// configure using wrapper instead of 'svelte/store'
import { configureStore } from './store';
export const someStore = configureStore<string>('hello');

// 2. Use them in components
import { someStore } from './store';
someStore.set('hi');
someStore.update((currentState: string) =>  currentState + ' world!');

Including custom actions

We can extend this wrapper and append custom actions as well, for example:

// Definition

const counterStore = createWritableStore<number>(7);

const increment = (value: number) => {
  counterStore.update((currentValue: number) => currentValue + value);
}
const decrement = (value: number) => {
  counterStore.update((currentValue: number) => currentValue - value);
}
const actions = { increment, decrement };

export const counter = {
  ...counterStore,
  ...actions
}

// Usage

counter.set(6); OR $counter = 6;
counter.update((v) => v * 2); OR $counter = $counter * 2;
counter.increment(3);
counter.decrement(3);

Easy Debugging

Debugging becomes super simple with this wrapper. Examples discussed below:

We now have a single point of the location where we can apply a debugger point and trace which component has triggered action to update the state.

const actions = {
  set: (value: T) => {
    // apply debugger here
    _set(value);
  },
  update: (callback: (param: T) => T) => {
    // apply debugger here
    _update(callback);
  },
};

Another debugging advantage is that this wrapper provides the option debugKey which if provided can print the trace in Redux browser-dev-tool using reduxify utility.

Some Context on reduxify utility: We can connect our custom stores with Redux dev tools. There is an awesome open-source utility available (https://github.com/unlocomqx/svelte-reduxify) that enables us to connect the svelte store to redux dev tools with the minimal code change. All we need is to pass our return values within reduxify callback.

CSS rules implied when working with percentage (%) unit

Aakash Goplani — Wed, 16 Feb 2022 21:42:17 +0000

Recently I was working on an assignment where-in I was positioning element w.r.t. parent element and setting height of 100%. I expected that, the child container will take up all the available parent height but that was not the case. On digging-down further, I understood few of basic CSS principles which I can summarize in two sections:

Using percentage unit on an element with position property set.
Fixing height set to 100% on an element with position property set.

Using percentage unit on an element with `position` property set

Using percentage unit on an element with position set to fixed

When we set position fixed on an element, it gets detached from the regular document flow. So the parent of such element is not the nearest div but the viewport!

here child element (with red border) has position set to fixed.
if we use percentage here, e.g. width: 60% then it will be 60% of the viewport's width and NOT that of parent (with blue border) width
reason is, when we used fixed property, the element gets detached from regular DOM flow & now the reference parent element will be viewport

Using percentage unit on an element with position set to absolute

When we set position absolute on an element, the parent of such element is the nearest element with position set to either of relative, absolute, fixed or sticky. In other words parent element will be the element with position property other than static (browser default). The dimension includes length of content + padding.

here child element (with red border) has position set to absolute.
if we use percentage here, e.g. width: 60% then it will be 60% of the parent element's width.
here width = content width of parent + padding. Example, If parent element has 16px of padding set, 1px of border and 16px of margin and the content takes dimension of (900 x 400). With these figures, the parent element's will be calculated as 900 + 16 + 16 = 932px i.e. width of content plus padding. So the child's width will be 60% of 932px.

Using percentage unit on an element with position set to relative or static

When we set position relative or static on an element, the parent of such element is the nearest block level element. The dimension includes length of content only.

here child element (with red border) has position set to relative.
if we use percentage here, e.g. width: 60% then it will be 60% of the parent element's width.
here width = content width of parent. Example, If parent element has 16px of padding set, 1px of border and 16px of margin and the content takes dimension of (900 x 400). With these figures, the parent element's will be calculated as 900px i.e. width of content. So the child's width will be 60% of 900px

Fixing height set to 100% on an element with `position` property set

Using percentage unit on an element with position set to relative or static

As discussed above, setting position to relative makes the parent reference element to the nearest block level element. So the height will be inherited from the nearest parent (body, in this case). It will push the entire content after the backdrop, refer the screenshot below:

Using percentage unit on an element with position set to absolute & fixed

When using absolute position, the parent reference element to the nearest element with position property other than static. In our example (refer stackbliz) it will be viewport, which will be the same for fixed as well. So the height will be inherited from the viewport and it will overlap all the body elements, refer the screenshot below:

stackblitz example

A simple approach towards handling errors in Angular

Aakash Goplani — Sun, 06 Feb 2022 09:51:39 +0000

Angular errors can be broadly classified into two types:

HTTP Errors
Client Errors

HTTP errors occurs whenever we deal with external APIs example, we made call to an endpoint and the network went down or while making the call server was not able to process the request properly and in return sends back error etc. All such scenarios which involve server's response status of 5xx and 4xx role comes under this category. In Angular, they are identified by HttpErrorResponse.

Client (Browser) Error is the error that mostly occurs at runtime because of developers mistake while writing the code. Types of these errors are: EvalError, InternalError, RangeError, ReferenceError, SyntaxError, URIError, TypeError. One such example:

(windows as any).abc.pqr = '';
// here property `abc` is not defined on global window object so
// `(windows as any).abc` will result into undefined and
// undefined.pqr will throw TypeError: stating that we are
// trying to set something on a property that does not exists

So any such errors that are induced by developers comes under Client (Browser) Error category.

Under both the circumstances its the end user that suffer the most. Whenever any such error occurs, execution of JavaScript stops and the screen freezes giving end user a bad experience. So, the good practice is to handle such errors and perform a relevant action like routing users to error page and displaying some custom message like Something Went Wrong! Please try again later!

Angular comes up with class ErrorHandler that provides default method handleError(error: Error) which we can utilize to catch those errors.

@Injectable()
class MyErrorHandler implements ErrorHandler {
  handleError(error: Error) {
    // do something with the exception like router.navigate(['/error-page']);
  }
}

We can use handleError(error: Error) to catch the error and redirect user to a generic error-page. One problem here is how do we inject the helper service in our custom ErrorHandler implementation?

If we inject the service as we generally do

constructor(private router: Router){}

This will throw error:

Error: NG0200: Circular Dependency in DI detected for ErrorHandler

Angular creates ErrorHandler before providers otherwise it won't be able to catch errors that occurs in early phase of application. Hence the providers will not be available to ErrorHandler. So, we need to inject dependent services using injectors.

@Injectable()
class MyErrorHandler implements ErrorHandler {
  constructor(private injector: Injector){}

  handleError(error: Error) {
    const router = this.injector.get(Router);
    router.navigate(['/error-page']);
  }
}

This solves one problem but leads to another.

Navigation triggered outside Angular zone, did you forget to call ngZone.run()

The problem here is exactly same as before while injecting our helper services. ErrorHandle runs outside of regular ngZone. So, the navigation should take place outside of the zone so that regular flow of Change Detection is not hampered

@Injectable()
class MyErrorHandler implements ErrorHandler {
  constructor(
    private injector: Injector,
    private zone: NgZone,
  ){}

  handleError(error: Error) {
    const router = this.injector.get(Router);
    this.zone.run(() => router.navigate(['/error-page']));
    console.error('Error Caught: ', error);
  }
}

Once we had achieved this, we need to provide this service to root module, example AppModule:

@NgModule({
  providers: [{provide: ErrorHandler, useClass: MyErrorHandler}]
})
class MyModule {}

We can add more customization to above handleError method

handleError(error: Error) {
  if (error instanceof HttpErrorResponse) {
    // HTTP related error
  } else if (error instanceof TypeError || error instanceof ReferenceError) {
    // Runtime exceptions mostly induced by Developer's code
  } else {
    // catch-all: catch rest of errors
  }
}

Create a pull request from a reverted remote branch

Aakash Goplani — Sun, 23 Jan 2022 19:30:09 +0000

Recently I landed across the situation where I had made commits directly to dev branch (which happens to be our release branch) instead of feature branch.

The general process that is followed in my company (and perhaps many others) is that we make changes to our feature branch and raise a pull request against dev (release) branch which is then reviewed and finally merged.

Accidently I pushed commits directly to dev branch instead of feature branch & I quickly reverted those commits back by simple git command

git revert <revert-commit-hash>
git commit -m "reverting accidental commits"
git push

After that I quickly checked out to my feature branch, made those changes again, pushed all changes to feature branch. As per next step, I had to raise PR of my latest changes against dev branch, and when I did that, I got message:

There isn’t anything to compare.

dev is up to date with all commits from feature branch. Try switching the base for your comparison.

The problem here is dev branch is ahead of the feature branch (because of revert commit). You will notice that your previous work which was reverted will be gone! The solution to this is reverting the reverted commit!

I had to follow 4 steps to fix this problem which I read from this awesome article

Step 1: Create and checkout to a new branch tracking dev branch

git checkout -b temp-branch -t dev

Step 2: Revert the commit that was made by mistake (here commit will be reverted back from dev branch since our temp branch is tracking dev)

git revert <revert-commit-hash>
git commit -m "reverting the reverted commits"
git push -u origin temp-branch

Step 3: Checkout the original feature branch

git checkout feature-branch

Step 4: Raise PR against dev branch

git push -u origin feature-branch

Pictorial representation of scenarios discussed above:

Angular Dynamic Form Validation - Template and Reactive Forms

Aakash Goplani — Sun, 23 Jan 2022 19:25:12 +0000

In this article I will present a way to validate Angular forms, both - model driven and template driven.

For this we will need two directives:

(1) form-control-validation: validates single input (form) control

(2) form-group-directive: validates group of form controls.

These directives will be attached to input elements & hence we can easily access core ngModel / FormControl instances and validate them.

We will use concept of dynamic components to create Error Component that has custom error validation message & inject it in DOM.

This is general overview of what we are trying to implement:

DOM Structure:

As mentioned we will be injecting those directives on input elements within DOM, one thing that we need to take care of is DOM structure. The whole POC is designed with the concept that directive will search for the nearest div / span with class "form-group" and attach the dynamic component with error message as child of that div / span.

So all our input elements must be wrapped within "form-group" class. Example:

<!-- snippet from template form -->
<div class="form-group user-data" ngModelGroup="userData" appFormGroupValidation validationMsgId="userData">
  <div class="firstname">
    <label for="firstname">First Name:</label>
    <input type="text" class="form-control" ngModel name="firstname" required [pattern]="validationPatterns.name" />
  </div>
  <div class="lastname">
    <label for="lastName">Last Name:</label>
    <input type="text" class="form-control" ngModel name="lastName" required [pattern]="validationPatterns.name" />
  </div>
</div>
<!-- snippet from reactive form -->
<div class="form-group address">
  <label for="address" for="address">Address:</label>
  <textarea formControlName="address" rows="3" class="form-control" appFormControlValidation validationMsgId="address" [pattern]="validationPatterns.address" required></textarea>
</div>

Directives:

We will be creating two directives - appFormControlValidation and appFormGroupValidation.

appFormControlValidation - validates single input element i.e. ngModel (in case of template driven form) and FormControlName (in case of model driven form). It iterates over the object to check for "validator" property (only if "errors" property is defined) & sets the error to the input control in case of falsy value and removes the error in case of truthy value.

if (this.control?.control?.validator && (this.control.control.validator(this.control.control) && this.control?.control?.validator(this.control?.control)?.hasOwnProperty('required'))) {
  // Need to add required error - template driven forms.
  const targetFormControl = this.control.control;
  targetFormControl.setErrors({ ...targetFormControl.errors, required: true });
} else if (this.control.validator && (this.control.validator(this.control as any) && this.control?.validator(this.control as any)?.hasOwnProperty('required'))) {
  // Need to add required error - reactive forms.
  const targetFormControl = this.control?.control;
  targetFormControl?.setErrors({ ...targetFormControl?.errors, required: true });
}

appFormGroupValidation - validates group of input elements i.e. FormGroup. It works exactly same as previous directive i.e. iterates over the object to check for "validator" property (only if "errors" property is defined) & sets the error to the input control in case of falsy value and removes the error in case of truthy value.

this.targetFormGroup = (this.container as NgModelGroup).control;
if (this.targetFormGroup?.statusChanges && !this.statusChangeSubscription) {
  this.statusChangeSubscription = this.targetFormGroup.statusChanges.subscribe(
  (status) => {
    if (status === 'INVALID' && (this.targetFormGroup.touched)) {
      this.showError();
    } else {
      this.removeError();
    }
  });
}

Dynamic component:

Once the validation is done, we display error messages dynamically using concept of Angular Dynamic Components.

As soon as the validation is falsy i.e. user typed incorrect input, we invoke component factory resolver with view reference of given input element & inject the error component dynamically. Once the user has corrected the input value, we remove that reference (dynamic component) from the DOM.

if (dynamicItem.component) {
  const componentFactory = 
  this.componentFactoryResolver.resolveComponentFactory(dynamicItem.component);
  const parent = parentNode || vcr.element.nativeElement;
  if (parent.innerHTML.indexOf(componentFactory.selector) < 0) {
    vcr.clear();
    const componentRef = vcr.createComponent(componentFactory);
    const newChild = componentRef.injector.get(ErrorComponent).elementRef.nativeElement;
    this.renderer.appendChild(parentNode || vcr.element.nativeElement, newChild);
    (componentRef.instance as DynamicComponent).data = dynamicItem.data;
  }
}

Helper Functions:

In this POC, we need to helper utilities:

Dynamic error message generation service:
- It enables to generate error message dynamically.
- We can provide the key via validationMsgId input property of directive. This key is use to construct error message which we then inject in DOM.
- Example: If the given field is required, then ngModel / FormControlName will have error property set to { required: true }. This service picks up the required key and appends it to validationMsgId (say for example address) provided by user i.e. address-required. If the given field has any pattern and id provided by user is "firstname", so generate key will be "firstname-pattern"
- If id is not provided by user, it defaults to "generic-required".

   <input type="text" appFormControlValidation validationMsgId="address" required />

   const errorMessages = {
     'generic-required': 'This field is required',
     'generic-pattern': 'Pattern does not match',
     'address-required': 'Please enter complete postal address',
     'address-pattern': 'Only Alpha-Numeric values and characters like `_ . / &` are allowed'
   };
   getValidationMessage(id = '-required'): string {
       return this.errorMessages[id] || this.errorMessages[`generic-${id.split('-')[1]}`];
   }

Validation on form submit:
- Our directives only get invoked in case of "blur" or "change" event i.e. only when user interacts with the field. What if user never interacts with fields and directly tries to submit the form?
- In that use case, we need a mechanism to let user know to provide valid input before submission.
- On every submission, we can loop over FormGroup, mark all inputs as "dirty" and "touched" and re-validate them using updateValueAndValidity(), this enables Angular to perform validation once more.
- To optimize this, we can add { onlySelf: true } to update value and validity for given control only and not its parent elements.

   const validateForm = (group: FormGroup): void => {
     Object.keys(group.controls).forEach((key: string) => {
       const value: AbstractControl = group.controls[key];
       if (value instanceof FormGroup) {
         value.markAsDirty();
         value.markAllAsTouched();
         validateForm(value);
         value.updateValueAndValidity({ onlySelf: true });
       } else {
         value.markAsDirty();
         value.markAsTouched();
         value.updateValueAndValidity({ onlySelf: true });
       }
    });
   };

StackBliz Example

DEV Community: Aakash Goplani

Comprehensive Guide to SvelteKitAuth: Secure Authentication for SvelteKit Apps

Chapter 1: Introduction to SvelteKitAuth

Chapter 1(b): How OAuth Operates: A Simple Breakdown

Chapter 2: Setting Up Auth0 and Adding SvelteKitAuth to Your App

Chapter 3: Step-by-Step Guide to Using built-in (Auth0) OAuth provider with SvelteKitAuth

Chapter 4: Step-by-Step Guide to using custom OAuth provider with SvelteKitAuth

Chapter 5: How to Integrate Multiple OAuth Providers in SvelteKitAuth

Chapter 6: Enhancing SvelteKitAuth with Custom Type Additions

Chapter 7: Streamlining Client-Side Sign-In and Sign-Out Processes

Chapter 8: Optimizing Server-Side Login and Logout Processes

Chapter 9: User Sign Out: Application vs OAuth Provider

Chapter 10: How to Manage Sessions in SvelteKit with SvelteKitAuth

Chapter 11: How to Implement Refresh Token Rotation in SvelteKitAuth

Chapter 12: How to Exchange Data Between Client and Server Using SvelteKitAuth

Chapter 13: Steps to Build Custom Pages and Handle Events in SvelteKitAuth

Chapter 14: Managing Shared Sessions Across Multiple Applications in SvelteKitAuth

Chapter 15: Drawbacks of SvelteKitAuth You Should Know

Conclusion

Internationalization in SvelteKit with svelte-i18n, sveltekit-i18n and typesafe-i18n

Internationalization in SvelteKit with svelte-i18n

Application Structure

Integration with SvelteKit

Internationalization in SvelteKit with sveltekit-i18n

Application Structure

Integration with SvelteKit

Internationalization in SvelteKit with typesafe-i18n

Application Structure

Integration with SvelteKit

Comparing i18n libraries in SvelteKit: svelte-i18n, sveltekit-i18n and typesafe-i18n

svelte-i18n

Features

Ease of Use

Size

Community Support

Limitations

sveltekit-i18n

Features

Ease of Use

Size

Community Support

Limitations

typesafe-i18n

Features

Ease of Use

Size

Community Support

Limitations

Avoid shared state on the server in SvelteKit - Be extra cautious when using stores in SSR mode

What is the problem?

How to fix this problem?

Migration Guide from Routify to SvelteKit Router

What is the need for migration?

Does Routify support SvelteKit?

Process of Migration

Generate Breadcrumb and Navigation in SvelteKit

SvelteKitAuth with Salesforce OAuth provider

Working with a built-in provider

Working with a custom provider

Wrapping Up

SvelteKit Authentication using SvelteKitAuth and OAuth providers: A Comprehensive Guide

What is SvelteKitAuth?

Why choose SvelteKitAuth?

How does SvelteKitAuth work under the hood?

How does OAuth work?

Configuring SvelteKitAuth with Auth0

State Management with Custom Svelte Store Wrapper

Why do we need Custom Store?

Custom Store in Action

How to use this wrapper

Including custom actions

Easy Debugging

CSS rules implied when working with percentage (%) unit

Using percentage unit on an element with position property set

Fixing height set to 100% on an element with position property set

A simple approach towards handling errors in Angular

Create a pull request from a reverted remote branch

Pictorial representation of scenarios discussed above:

Angular Dynamic Form Validation - Template and Reactive Forms

Using percentage unit on an element with `position` property set

Fixing height set to 100% on an element with `position` property set