Core Service

Introduction

Core Service is a monolith service for critical Logto duties. The source code is in @logto/core.

note:

Core Service and SDK core are two separate concepts. See SDK convention for the differences.

To simplify, we divide Core Service into four major modules:

Name	Description	Mount Path
OIDC Provider	An OpenID Provider.	/oidc
Logto API	Management API, Experience API and Account API.	/api
Frontend proxies	HTTP proxies or static file serving for frontend projects.	See Frontend proxies for details.

Backend APIs, including OIDC, are built within the core package, while frontend proxies depend on the corresponding sibling packages in the Logto monorepo.

OIDC Provider

Logto uses the amazing certified OpenID Connect implementation node-oidc-provider under the hood. The provider is mounted at /oidc, and you can check relative configurations and files in packages/core/src/oidc.

The OIDC Userinfo Endpoint is available and mounted at /oidc/me.

info:

If you want to directly call OIDC APIs, remember to set header Content-Type: application/x-www-form-urlencoded.

Enabled OpenID features

• OpenID Connect Core
• OpenID Connect Discovery
• OpenID Connect RP-Initiated Logout
• OpenID Connect Back-Channel Logout
• OAuth 2.0
• OAuth 2.0 Token Introspection
• OAuth 2.0 Token Revocation
• OAuth 2.0 Resource Indicators
• Proof Key for Code Exchange (PKCE)

Logto API

Management API

Management API is a set of APIs that manage and update Logto data. Only users with the admin role have access to them.

Head to API references to see the details.

To access the API programmatically, see Interact with Management API.

Experience API

Experience API is a set of dedicated endpoints that support custom sign-in interface interactions.

These APIs enable developers to implement core authentication features including sign-in, sign-up, password reset, social account binding, and multi-factor authentication (MFA). To implement these features, your custom UI needs to interact with the Experience API.

To better understand the user flows and implementation details:

• Check out Develop your custom UI guide to learn how to use Experience API to build your custom experience UI
• Refer to Experience API references for detailed API documentation
• Read the Experience API design RFC for in-depth technical specifications and examples

Account API

Account API is a comprehensive set of APIs that gives the end users direct API access without needing to go through the Management API, here is the highlights:

• Direct access: The Account API empowers end users to directly access and manage their own account profile without requiring the relay of Management API.
• User profile and identities management: Users can fully manage their profiles and security settings, including the ability to update identity information like email, phone, and password, as well as manage social connections. MFA and SSO support are coming soon.
• Global access control: Admin has full, global control over access settings, can customize each fields.
• Seamless authorization: Authorizing is easier than ever! Simply use client.getAccessToken() to obtain an opaque access token for OP (Logto), and attach it to the Authorization header as Bearer <access_token>.

With the Logto Account API, you can build a custom account management system like a profile page that is fully integrated with Logto.

Check out Account settings by Account API to learn how to leverage Account API to build your own account settings page.

Refer to Account API references for detailed API documentation.

Frontend proxies

A frontend proxy is a middleware function that serves a frontend project in an environment-related way:

• If it's development, it proxies HTTP requests to the frontend dev server.
• If it's production, it serves static frontend files directly.

Logto has three frontend proxies:

Name	Frontend Package	Mount Path
Admin Console proxy	/packages/console	/console
Demo app proxy	/packages/demo-app	/demo-app
UI (sign-in experience) proxy	/packages/ui	/

note:

You may notice that the UI proxy uses the root path. Unlike other proxies, the UI proxy is a fallback proxy which means it only takes effect when no other proxy is matched.