Key Libraries and Packages Used in the Logto Open-Source Identity Platform

Logto is built as a Node.js monorepo centered around Koa for the HTTP server, oidc-provider for OpenID Connect flows, PostgreSQL with Slonik for data persistence, Redis for caching, and a collection of internal @logto/* packages that compose the admin console, sign-in experience, and connector ecosystem.

The logto-io/logto repository organizes its codebase as a pnpm workspace monorepo, splitting functionality across focused packages. Understanding the key libraries and packages used in the Logto project reveals how the platform balances standards-compliant authentication with cloud-native scalability and a modern React-based management interface.

Core Server Dependencies

HTTP Layer and OIDC Implementation

At the heart of the Logto server lies Koa (koa), the lightweight HTTP framework that hosts the OpenID Connect provider and management APIs. According to packages/core/package.json, Koa provides the middleware-first architecture used throughout the request lifecycle.

oidc-provider (oidc-provider) implements the RFC-compliant OpenID Connect and OAuth 2.0 flows. Logto extends this library with custom grant types and UI integrations rather than implementing the protocol from scratch. The bootstrap logic in packages/core/src/main.ts wires the OIDC provider into the Koa application.

Database and Caching Layers

pg (pg) serves as the PostgreSQL driver for all persistent storage, including user data, tenant configurations, and session records. Logto pairs this with @silverhand/slonik, a typed PostgreSQL query builder used throughout the data layer to enforce SQL type safety.

For volatile, high-speed data, Logto uses redis (redis). As implemented in packages/core/src/main.ts, Redis handles token caching, rate-limit counters, and JWKS caching to minimize database load on authentication requests.

Authentication and Security Libraries

jose (jose) handles all JSON Web Token operations, including signing access tokens and verifying encryption keys. The library is essential for the token issuance and introspection endpoints defined in the core package.

zod (zod) provides runtime schema validation for request payloads and internal data structures, catching malformed inputs before they reach business logic.

For passwordless and enterprise authentication, Logto integrates @simplewebauthn/server for WebAuthn support and @authenio/samlify-node-xmllint for SAML parsing and validation in enterprise connectors.

Cloud Storage and Connector Ecosystem

Logto supports multiple cloud providers for user-uploaded assets such as avatars and custom UI files. The core package includes @aws-sdk/client-s3, @azure/storage-blob, and @google-cloud/storage as optional dependencies, allowing operators to configure their preferred object storage backend.

Connectors rely on HTTP clients and messaging libraries to interface with external services. axios and got handle outbound API calls for social login providers, while node-forge, nodemailer, and various SMS SDKs (Twilio, SendGrid, etc.) power email and SMS delivery. A representative example is found in packages/connectors/connector-twilio-sms/package.json, which demonstrates how these dependencies are isolated within individual connector packages.

Internal Monorepo Structure

The @logto/* namespace contains the platform's internal architecture:

• @logto/core: The server-side application that wires together Koa, the OIDC provider, database connections, and connector loading. Entry point: packages/core/src/main.ts.
• @logto/console: Vite-powered React SPA for the admin dashboard, using react-router and i18next for navigation and internationalization.
• @logto/experience: The sign-in UI experience, also a React SPA, handling the frontend flow for authentication methods.
• @logto/cli: Command-line tooling for installation, database migrations, and configuration.
• @logto/shared: Reusable utilities and type definitions shared across packages.
• @logto/connector-kit: Base types and utilities for building custom connectors.

The root package.json declares the workspace and references @logto/cli and @logto/translate as entry points, while individual packages declare their own internal dependencies.

Code Examples

The following snippets illustrate typical usage patterns for three core libraries in the Logto codebase:

Starting a Koa server with tenant isolation middleware:

import Koa from 'koa';
import tenantGuard from '@logto/core/src/middleware/koa-tenant-guard.js';

const app = new Koa();
app.use(tenantGuard());
app.listen(3001, () => console.log('Logto core listening on 3001'));

Issuing a JWT using the jose library:

import { SignJWT } from 'jose';
import { EnvSet } from '@logto/core/src/env-set/index.js';

const secret = new TextEncoder().encode(EnvSet.values.jwtSecret);
const token = await new SignJWT({ sub: 'user-id-123' })
  .setProtectedHeader({ alg: 'HS256' })
  .setIssuedAt()
  .setExpirationTime('2h')
  .sign(secret);

Creating an authorization URL with the OIDC provider:

import Provider from 'oidc-provider';

const oidc = new Provider('http://localhost:3001', {/* config */});
const client = await oidc.Client.find('my-client-id');
const url = client.authorizationUrl({
  scope: 'openid profile email',
  redirect_uri: 'https://app.example.com/callback',
});
console.log('Visit:', url);

Key Source Files

• packages/core/package.json: Lists all external runtime dependencies including Koa, oidc-provider, pg, and redis.
• packages/core/src/main.ts: The bootstrap file that initializes the Koa server, Redis connections, and OIDC provider.
• packages/core/src/middleware/koa-tenant-guard.ts: Example middleware enforcing tenant isolation in multi-tenant deployments.
• packages/console/package.json: Defines the React SPA dependencies including Vite, React Router, and i18next.
• packages/connectors/connector-twilio-sms/package.json: Illustrates connector-specific dependencies like axios and provider SDKs.

Summary

• Logto uses Koa as its HTTP framework and oidc-provider for standards-compliant OpenID Connect implementation.
• PostgreSQL with Slonik provides the type-safe data layer, while Redis handles caching and session storage.
• jose manages JWT operations, zod validates schemas, and WebAuthn/SAML libraries enable modern and enterprise authentication methods.
• The monorepo is organized under @logto/* packages, with core for the server, console for the admin UI, and connectors for third-party integrations.
• Cloud storage SDKs (AWS, Azure, Google Cloud) and HTTP/email libraries support flexible deployment options and connector extensibility.

Frequently Asked Questions

Why does Logto use Koa instead of Express?

Logto chose Koa for its lightweight, middleware-first architecture that uses modern async/await patterns by default. This design simplifies the composition of authentication-related logic such as rate-limiting, error handling, and tenant isolation, as seen in packages/core/src/middleware/koa-tenant-guard.ts.

Can I use a different database instead of PostgreSQL?

According to the source code in packages/core/package.json, Logto tightly couples its data layer to PostgreSQL using the pg driver and @silverhand/slonik query builder. While the architecture abstracts database access, migrating to another database would require replacing these specific dependencies and updating the schema management logic.

How does Logto handle session storage without hitting the database on every request?

Logto utilizes Redis as an in-memory cache for volatile data such as access tokens, rate-limit counters, and JWKS key sets. This caching layer, initialized in packages/core/src/main.ts, reduces database load by serving frequently accessed authentication data from memory rather than querying PostgreSQL.

What is the purpose of the @logto/connector-kit package?

@logto/connector-kit provides shared types, utility functions, and base classes used by all connector implementations in the packages/connectors/ directory. It standardizes how connectors interact with external SMS, email, and social login providers, ensuring consistent error handling and request validation across the ecosystem.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}