🧱 Core Service
Introduction
Core Service is a monolith service for critical Logto duties. The source code is in /packages/core.
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 |
| Management API | APIs for managing Logto. The admin role is required. | /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.
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
- OAuth 2.0 Token Revocation
- OAuth 2.0 Resource Indicators
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.
It's mounted at /api. Head to API references to see the details in your browser, or use GET /api/swagger.json for a Swagger result in JSON.
To access the API programmatically, see 🚝 Interact with Management API.
Authentication
Admin Console heavily depends on these APIs, while you can also call them manually.
You need to have an Access Token that satisfies the following criteria:
- It's a valid token
- It's issued by your Logto instance
Its audience (
aud, i.e. the API identifier) points tohttps://[your-tenant-id].logto.app/api.Its
scopeincludes"all".
Put that token in the Authorization field of HTTP headers with the Bearer format (Bearer YOUR_TOKEN), and you are good to go.
User API
We provide a standard OIDC Userinfo Endpoint mounted at /oidc/me.
Authentication
You need to have an Access Token that satisfies the following criteria:
- It's a valid token
- It's issued by your Logto instance
Its audience (
aud, i.e. the API identifier) points tohttps://[your-tenant-id].logto.app/api.
Put that token in the Authorization field of HTTP headers with the Bearer format (Bearer YOUR_TOKEN), and you are good to go.
About refresh token reuse interval
You may notice Refresh Token has a rotation delay (3s). This delay helps avoid concurrency issues when exchanging the rotating refresh token multiple times within a given timeframe.
During the leeway window (in seconds), the consumed refresh token will still be considered as valid.
This is useful for distributed apps and serverless apps like Next.js, in which there is no shared memory.
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 | / |
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.