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

> Discover the core Node.js libraries and packages powering the Logto open-source identity platform. Explore Koa, oidc-provider, PostgreSQL, Redis, and more.

- Repository: [Logto/logto](https://github.com/logto-io/logto)
- Tags: internals
- Published: 2026-07-06

---

**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`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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:

```typescript
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:

```typescript
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:

```typescript
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`](https://github.com/logto-io/logto/blob/main/packages/core/package.json): Lists all external runtime dependencies including Koa, oidc-provider, pg, and redis.
- [`packages/core/src/main.ts`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/packages/core/src/middleware/koa-tenant-guard.ts): Example middleware enforcing tenant isolation in multi-tenant deployments.
- [`packages/console/package.json`](https://github.com/logto-io/logto/blob/main/packages/console/package.json): Defines the React SPA dependencies including Vite, React Router, and i18next.
- [`packages/connectors/connector-twilio-sms/package.json`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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`](https://github.com/logto-io/logto/blob/main/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.