Logto JS Core SDK

@logto/js is the foundation package underneath Logto’s browser, Node, Next.js, React, Vue, and other framework SDKs. It implements the raw OIDC protocol mechanics — building sign-in authorization URIs, exchanging authorization codes or refresh tokens for access/ID tokens, decoding and validating ID/access token claims, fetching user info, and revoking tokens — without binding to any specific runtime or storage strategy.

Most applications never import it directly; instead they use one of the higher-level SDKs (@logto/browser, @logto/node, @logto/react, etc.) built on top of it. Teams building a Logto SDK for an unsupported framework are pointed here as the starting point, since it isolates all the OIDC request/response shaping (snake_case-to-camelCase conversion, PKCE parameters, scope handling) that every framework SDK would otherwise have to reimplement.

Because it has no framework or DOM dependencies, it also runs in edge and non-browser JavaScript environments, which is why Logto describes it as suitable for “browser, and edge computing” contexts alongside Node.js.

What You Get

• generateSignInUri builds a fully-formed OIDC authorization URL with PKCE challenge, scopes, prompts, direct sign-in, and extra parameters already encoded
• fetchTokenByAuthorizationCode and fetchTokenByRefreshToken exchange codes or refresh tokens for access/ID tokens via a pluggable Requester function you supply
• decodeIdToken and decodeAccessToken parse and runtime-validate JWT claims, throwing typed errors on malformed tokens instead of returning undefined
• fetchUserInfo and fetchOidcConfig wrap the userinfo and OIDC discovery endpoints with camelCase response typing
• A LogtoError/LogtoRequestError/OidcError hierarchy with fixed, documented error codes instead of ad hoc string errors
• Zero DOM or Node-specific APIs, so the same package runs in browsers, Node, and edge runtimes

Common Use Cases

• Building a new framework SDK - a team wants Logto support for a framework Logto doesn’t officially maintain, and starts from @logto/js instead of re-implementing OIDC token exchange
• Custom auth flow inside an existing app - a developer needs finer control over the sign-in redirect or token handling than a higher-level SDK exposes, and calls the core functions directly
• Edge middleware token validation - an edge function decodes and checks ID/access token claims without pulling in a browser- or Node-specific SDK
• Debugging token exchange issues - a maintainer of a Logto-based app traces a sign-in bug down to the exact request/response shape this package sends and parses

Under The Hood

Architecture The package is organized into three thin layers under src/: core/ (one file per OIDC operation — sign-in.ts, fetch-token.ts, oidc-config.ts, revoke.ts, sign-out.ts, user-info.ts), utils/ (token decoding, scope merging, callback URI verification, error types), and consts/ (OIDC query-parameter and grant-type enums). Every network-touching function takes a Requester function as an explicit parameter rather than importing fetch directly, so the package has no runtime HTTP dependency and framework SDKs inject their own fetch wrapper. src/index.ts re-exports all four layers as the public surface — there is no internal state or class to instantiate, every export is a pure function.

Tech Stack Written in TypeScript, built with Rollup into ESM-only output (type: module), and typed against @silverhand/essentials for shared utility types (KeysToCamelCase, Nullable) and camelcase-keys to convert OIDC’s snake_case JSON responses into camelCase TypeScript types. It sits inside a pnpm-workspace monorepo alongside the browser, Node, React, Vue, Angular, and other framework packages that depend on it, sharing a root @silverhand/eslint-config and @silverhand/ts-config.

Code Quality Every file in core/ and most of utils/ has a matching *.test.ts run through Vitest, asserting exact request shapes (URL, headers, body) and response mappings rather than just “does not throw.” Token decoding uses hand-written runtime type guards (assertIdTokenClaims, assertAccessTokenClaims) that throw typed errors on shape mismatches instead of trusting unknown JWT payloads, and the CI pipeline runs a full build, lint, and coverage-instrumented test pass (with automatic retries for flaky runs) on every push and PR.

What Makes It Unique Rather than each framework SDK independently re-implementing OIDC request construction and token parsing, Logto centralizes it in one dependency-free package and explicitly documents it as the recommended starting point for building unsupported-framework SDKs. The Requester-injection pattern keeps it usable in any JavaScript runtime — browser, Node, or edge — without conditional imports or environment detection.