FoxAuth

---

OAuth-server.ts 是一个源代码可用（FSL-1.1-ALv2）、符合标准的授权服务，使用 TypeScript 编写，由 Bun 和 Elysia 驱动。它从零开始实现 OAuth 2.0 和 OpenID Connect，让你完全掌控自己的身份基础设施，避免被供应商锁定。

功能

大多数协议能力都由具名功能标志控制，关闭某个标志意味着完全不会提供该能力的端点。因此，此列表按默认安装即可获得的功能，以及需要你主动启用的功能划分——这一区别至关重要，并非只是编辑上的安排。

开箱即用

• 授权码流程与 PKCE — 根据 OAuth 2.1，所有客户端都必须使用 PKCE，无论是公共客户端还是机密客户端
• OpenID Connect — OIDC Core 1.0，包含 ID 令牌、UserInfo 端点和发现机制
• 授权响应签发者标识 — 每个授权响应都包含 iss（RFC 9207）
• 资源指示符 — 通过 resource 限定受众的令牌（RFC 8707）
• 刷新令牌授权 — 支持轮换和重用检测；当受支持的 scopes 中包含 offline_access 时提供，此范围默认已包含
• 由 RP 发起的注销 — 可通过 GET 或表单 POST 发起，并包含确认步骤
• JWT 令牌 — 访问令牌和 ID 令牌使用密钥库中的算法签名；bun run db:setup 会配置一个初始 RS256 密钥，同时支持 ES256 和 EdDSA 密钥。密钥存储在数据库中，首次运行时生成，并发布在 /jwks；每个拥有独立地址的项目也会在自己的 jwks_uri 发布专属密钥
• 数据库支持的客户端 — 客户端存储在此服务自己的存储中，并通过管理 API、动态注册或 bun run db:setup 创建。没有静态客户端配置文件
• 管理控制台 — 项目、团队、OAuth 客户端和 API、管理员、终端用户及其群组、上游身份提供商、SCIM 配置连接、设置、SMTP、签名密钥和仅追加的审计记录
• 终端用户自助服务 — 邮箱验证和密码重置，均对每个身份设置尝试次数和冷却时间上限
• TOTP 第二因素 — 按项目配置，也可设为管理控制台的强制要求（RFC 6238）
• 成对主题标识符 — 按扇区生成 sub 值，并使用数据库中的值加盐
• 按来源限流 — 按路由类别分级，默认启用
• 登录暴力破解限流 — 按地址持久记录失败次数并逐步延长锁定时间，且无法区分被限流的拒绝和密码错误
• 安全标头 — HSTS、Permissions-Policy、框架嵌入和内容类型保护
• 通过数据控制 CORS — 仅当调用客户端所属项目列出某个来源时，才允许读取该来源
• 可插拔存储 — 适配器架构，支持 MongoDB、PostgreSQL 和内存实现
• 同意与登录界面 — 内置身份验证和同意页面（React + Ant Design）
• 基于范围的访问控制 — 精细控制每个客户端的范围
• 可扩展 — 提供 31 个具名行为扩展点（账户查找、交互策略、刷新令牌轮换、资源解析、成对标识符、RAR 处理等），可在调用时通过 addons.override() 替换

可选功能

这些功能已实现，默认关闭，设置标志后即可启用。可在控制台的 设置 中或在 ApplicationConfig 上设置；在控制台保存的更改会立即生效。

功能	标志
客户端凭据授权	clientCredentials.enabled
JWT bearer 授权，用于 ID-JAG（RFC 7523）	jwtBearer.enabled
令牌交换 — 签发 ID-JAG（RFC 8693）	tokenExchange.enabled
DPoP — 发送方受限令牌，包括 nonce（RFC 9449）	dpop.enabled
推送授权请求（RFC 9126）	par.enabled
令牌内省（RFC 7662）	introspection.enabled
令牌撤销（RFC 7009）	revocation.enabled
JWT 响应内省（RFC 9701）	jwtIntrospection.enabled
已签名的 UserInfo 响应	jwtUserinfo.enabled
动态客户端注册（RFC 7591）	registration.enabled
注册管理（RFC 7592）	registrationManagement.enabled
设备授权授权类型（RFC 8628）	deviceFlow.enabled
CIBA — 后通道身份验证	ciba.enabled
JARM — JWT 保护的授权响应	responseMode.jwt.enabled
请求对象（request / request_uri）	requestObjects.enabled
富授权请求（RFC 9396）	richAuthorizationRequests.enabled
mTLS 客户端身份验证和证书绑定令牌（RFC 8705）	mTLS.enabled
FAPI 配置文件行为	fapi.enabled
后通道注销	backchannelLogout.enabled
claims 请求参数	claimsParameter.enabled
令牌和响应加密	encryption.enabled
手动通过 Google、Microsoft、Apple 或 GitHub 登录，或通过其他 OIDC 提供方登录	federation.enabled
通过 MCP 管理 — 将同一管理 API 提供给 AI Agent	mcp.enabled
通过 SCIM 2.0 从 Microsoft Entra ID、Okta 或任何 SCIM 客户端预配项目的用户和群组	scim.enabled
Okta Universal Logout — 全局令牌撤销（单独草案已过期，因此选择启用）	globalTokenRevocation.enabled
错误存储记录（其读取接口始终提供，这是有意为之）	errorStore.enabled

快速开始

使用 Docker Compose

前提条件： Docker 和 Compose v2。

curl -O https://raw.githubusercontent.com/RedFox-Soft/OAuth-server.ts/main/docker-compose.yml
docker compose up

这会启动 MongoDB、配置架构和管理面板（此步骤只运行一次且可幂等执行），并在 http://localhost:3000 提供服务。打开 http://localhost:3000/admin——首次访问时会显示一次性设置页面，用于创建初始超级管理员。发现端点位于 http://localhost:3000/.well-known/openid-configuration。请在首次运行 docker compose up 前，将 docker-compose.yml 中的 ISSUER 设置为最终的公开 URL：预置管理员客户端的重定向 URI 仅在此时根据该值生成，之后更改该值不会通过重新运行设置来修复。

每次发布时，镜像都会发布到 ghcr.io/redfox-soft/oauth-server-ts，并使用版本号和 latest 作为标签。升级时，重新拉取并运行 docker compose up；设置步骤会再次运行且可安全重复。

从源代码构建

前提条件： Bun v1.3+，以及正在运行的 MongoDB 或 PostgreSQL 实例。

git clone https://github.com/RedFox-Soft/OAuth-server.ts.git
cd OAuth-server.ts
bun install

# Create .env — set MONGODB_URI, DATABASE_NAME, and ISSUER (see Configuration)

bun run db:setup   # collections, indexes, initial RS256 signing key, admin panel seed
bun run build      # bundles the console and sign-in screens into public/
bun start          # http://localhost:3000

配置架构时会创建初始签名密钥，因此无需配置密钥。如果服务器启动时发现密钥存储为空，也会自动生成并持久化密钥。

管理面板配置

bun run db:setup 还会配置管理面板：预留的“Administrators”项目和第一方 admin-panel OAuth 客户端。预置操作具有幂等性——升级现有安装后，请重新运行 bun run db:setup，确保管理客户端和项目存在。 首次访问 /admin 时，一次性设置页面会创建首位管理员，并将其加入超级管理员团队；该团队有活跃成员后，设置路由便会关闭。管理面板要求部署使用数据库，即 MongoDB 或 PostgreSQL（内存适配器不会在重启后保留预置数据）。

配置

变量	说明	示例
MONGODB_URI	MongoDB 连接字符串	mongodb://localhost:27017
DATABASE_NAME	要使用的数据库名称	OAuth
ISSUER	授权服务器的规范 URL	https://auth.example.com

签名密钥

签名密钥存储在数据库中，而非环境变量中——所有发行者的密钥都位于 bucketKeys 区域，包括实例自身的密钥。配置架构（bun run db:setup）时会创建初始 RS256 签名密钥；如果服务器启动时发现密钥存储为空，也会自动生成并持久化密钥。轮换密钥无需重启：生成密钥（会先发布），待每个实例都能提供该密钥后，将其提升为签名密钥，再停用旧密钥；旧密钥仍会继续用于验证一天。可通过控制台、管理 API 或 MCP（jwks_generate、jwks_promote、jwks_retire）执行这些操作。每种算法只能有一个密钥用于签名，因此 RS256 和 PS256 可以同时用于签名。

速率限制

系统按调用来源统计请求；当某个来源在时间窗口内超过其限额时，将拒绝请求并返回 429。拒绝会发生在端点执行任何工作之前，并附带 Retry-After，指明剩余秒数；响应正文采用标准 OAuth 错误格式、管理端自身的格式或 HTML 页面，具体取决于所访问的界面。不会发送 RateLimit-* 标头——这些标头会让探测限额的调用方准确得知限额。

限额根据路由类别分级设置，而非使用统一的数值，因为足以保护令牌端点的严格限额，可能会拒绝控制台所需的大量资源请求：

类别	适用范围	默认值
strict	令牌、授权、动态注册、PAR、设备、CIBA，以及所有会检查密钥或发送邮件的终端用户入口	60 / 60s
ordinary	其他未分类的所有内容——用户信息、内省、撤销、管理 API、MCP，以及其余交互界面	300 / 60s
public	静态资源、发现元数据、密钥集，以及所有跨源预检请求	1200 / 60s
exempt	仅 GET /health——拒绝存活探针会导致机器被移出负载均衡器	永不计数

所有设置都可以在管理控制台的 设置 → 速率限制 中配置，也可以直接在 ApplicationConfig 中配置。在控制台中保存的更改会立即生效，与其他服务器设置一样。

设置	默认值	说明
rateLimit.enabled	true	事件紧急关闭开关
rateLimit.trustedProxy	true	见下文——不存在普遍安全的取值
rateLimit.maxTrackedOrigins	10000	每个类别；限制限流器自身占用的内存
rateLimit.strict.max	60	配合 .windowSeconds 使用，默认值为 60
rateLimit.ordinary.max	300	配合 .windowSeconds 使用，默认值为 60
rateLimit.public.max	1200	配合 .windowSeconds 使用，默认值为 60

如果其中任一项不是正整数，服务器就会拒绝启动，而不会在限流功能被悄然禁用或彻底封锁的状态下继续提供服务。

rateLimit.trustedProxy 这个设置在两种取值下各有一种错误情况。 如果服务器前面有其他设备或服务（随附的 fly.toml 就是如此），请保持启用：若将其关闭，所有调用方都会被视为来自代理自身的地址，因此整个互联网共用一个额度，几秒内所有流量都会被拒绝。如果服务器直接暴露在外，请将其关闭：若保持启用，任何调用方都可以为每个请求设置一个新的 Fly-Client-IP 值，从而永远不会受到限流。

依赖此功能前需要了解的两个特性。 计数按实例分别统计并保存在内存中，因此有 N 台机器同时提供服务时，实际额度是配置值的 N 倍；实例重启会清除所有计数器。这是一种资源保护措施——限制单一来源对服务器造成的成本，而不是安全边界。必须绝对生效的限制是按身份实施的节流措施：验证码最多允许尝试五次；重新发送和密码重置请求受冷却时间限制并设有每日上限；密码登录入口则使用下文所述的暴力破解节流——这些限制均独立于此处的设置。

调整。 如果同一地址后有合法的服务器间集成，或许多用户共用一个企业 NAT，且开始遇到请求被拒绝的情况，请提高 strict.max。如果管理控制台加载时出现卡顿，请提高 public.max。内存压力较大时，请降低 maxTrackedOrigins。事件发生期间，将 rateLimit.enabled 设为 false 即可关闭整个限流功能；保存后立即生效。

登录暴力破解限流

失败的密码尝试会按项目和地址分别计数。一旦某个地址达到上限，该地址的登录入口就会关闭，并拒绝后续所有尝试——包括使用正确密码的尝试——直到限流窗口结束。每次进一步触发上限，关闭时间都会延长一倍，直至达到上限：默认依次为 15 → 30 → 60 分钟，这会将持续攻击限制在每天约 120 次猜测。连续 24 小时没有失败后，计数器会清零。

拒绝页面与普通的“用户名或密码无效”页面完全相同。页面绝不会透露存在限流、还剩多少次尝试，或入口何时重新开放，因为这些信息会让攻击者知道他们猜测的地址确实存在账户。出于同样的原因，没有账户的地址也会计数——计数器的存在只意味着有人输入了这个地址，仅此而已。而且，由于拒绝发生在查询账户之前，被拒绝的尝试不会产生密码哈希开销：针对单个地址的洪泛攻击不再只是失去猜测机会，也不再消耗 CPU。

与上文按来源限流不同，这些计数器会持久化保存，因此限流在重启后以及所有并发提供服务的机器上都有效。这使其成为安全边界，而非资源保护——也正因如此，特意没有提供关闭它的开关。

设置	默认值	说明
loginThrottle.failureCap	5	每个窗口内的尝试次数；最多为 100
loginThrottle.windowSeconds	900	首次锁定时长，也是递增曲线加倍计算的基准
loginThrottle.windowCeilingSeconds	3600	最长锁定时长；不得短于首次锁定时长，也不得超过 24 小时

有两种情况会立即清除计数器，而无需等待窗口结束：密码验证成功，以及已完成密码重置。后者是脱困途径——使用通过邮件发送的密钥，证明用户控制该地址，而猜测密码的攻击者并不具备这一点——因此，被锁定的用户无需一直等待。仅仅_请求_重置不会清除任何内容。

要求使用一次性验证码的项目，无论触发多少次，都只会保持在首次锁定时长：在这种情况下，猜中密码也无法让任何人登录，因此更长的锁定时间作用不大。这对保留的 Administrators 项目尤其重要：该项目的操作人员通过同一个入口登录，而且没有可用于脱困的自助重置功能——最坏情况下只需等待 15 分钟。要真正加固这个入口，应要求启用第二因素（Admins → Require an authenticator app）。

Docker

已发布镜像：

docker pull ghcr.io/redfox-soft/oauth-server-ts:latest
docker run -p 3000:3000 --env-file .env ghcr.io/redfox-soft/oauth-server-ts:latest

首次启动前，请先对同一个数据库运行一次 bun run db:setup（上方的 Compose 文件会替你执行）。

每个已发布镜像都经过签名，签名关联其摘要，并附带 SBOM 和构建来源证明。签名采用无密钥方式，因此验证时会指定获准生成该镜像的工作流，而不是密钥：

cosign verify \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github\.com/RedFox-Soft/OAuth-server\.ts/\.github/workflows/release\.yml@refs/tags/v' \
  ghcr.io/redfox-soft/oauth-server-ts:latest

读取 SBOM、构建记录和已签名的 SLSA 来源证明，请参阅另外三个命令。

若要改为在本地构建：

docker build -t oauth-server-ts .
docker run -p 3000:3000 --env-file .env oauth-server-ts

端点

大多数端点都受功能标志控制；标志关闭时，端点完全不会提供服务——不只是停止在发现结果中公布。拒绝响应会刻意做得与服务器不存在该路径时无法区分，因此，如果下方的请求返回 404，请先检查标志，再怀疑是否存在缺陷。可在管理控制台的 Settings 下设置标志，也可直接在 ApplicationConfig 上设置；在控制台中保存的更改会立即生效。

始终可用

端点	描述
GET /health	存活探针
GET /.well-known/openid-configuration	OpenID Connect 发现文档（内容反映已启用的功能）
GET /.well-known/oauth-authorization-server	面向纯 OAuth 客户端的授权服务器元数据（RFC 8414）；同一文档，但不含仅适用于 OpenID Connect 的成员
GET /.well-known/security.txt	安全联系信息和漏洞披露政策（RFC 9116）
GET /jwks	JSON Web 密钥集
GET, POST /auth	授权端点
POST /token	令牌端点

默认启用

由标志控制，但默认开启，除非你将其关闭。

端点	描述	标志
GET, POST /userinfo	UserInfo 端点	userinfo.enabled
GET, POST /logout	RP 发起的注销	rpInitiatedLogout.enabled
POST /logout/confirm	注销确认	rpInitiatedLogout.enabled

可选启用

默认安装中不会启用，需设置标志后才会启用。

端点	说明	标志
POST /par	推送授权请求（RFC 9126）	par.enabled
POST /token/introspect	令牌内省（RFC 7662）	introspection.enabled
POST /token/revocation	令牌撤销（RFC 7009）	revocation.enabled
POST /reg	动态客户端注册（RFC 7591）	registration.enabled
GET /reg/:clientId	读取客户端自己的注册信息	registration.enabled
PUT, DELETE /reg/:clientId	更新／删除注册信息（RFC 7592）	registrationManagement.enabled
POST /device/auth	设备授权（RFC 8628）	deviceFlow.enabled
GET, POST /device	设备流的用户代码输入页面	deviceFlow.enabled
POST /backchannel	客户端发起的后通道身份验证（CIBA）	ciba.enabled
POST, GET /mcp	通过 MCP 进行管理	mcp.enabled
GET /.well-known/oauth-protected-resource/mcp	/mcp 的受保护资源元数据（RFC 9728）	mcp.enabled
GET, POST /federation/callback	上游身份提供方回调	federation.enabled
/scim/v2/*（用户、组和发现）	SCIM 2.0 配置，在各项目的地址上提供	scim.enabled
POST /global-token-revocation	Okta Universal Logout，在各项目的地址上提供	globalTokenRevocation.enabled

读取自己的注册信息遵循 registration.enabled，而不是 registrationManagement.enabled：注册响应会向客户端提供该 URI，因此在启用注册时拒绝 读取会破坏该功能。只有修改操作才需要管理标志。

路由系列

这些路由通过重定向或控制台访问，而不是直接调用，因此以下按系列介绍，而不逐一列出。

系列	入口点	描述
终端用户交互界面	/ui/:uid/…	登录、授权、注册、TOTP 挑战和注册、忘记密码、流程恢复。联合登录路由（/ui/:uid/federation/…）需要启用 federation.enabled
邮箱验证	/verify-email	验证、输入验证码、重新发送
密码重置	/reset-password	自助重置
管理控制台 + API	/admin、/admin/api	项目、团队、客户端、管理员、终端用户、联合身份提供商、设置、SMTP、签名密钥、审计跟踪、错误存储
静态资源	/public/…	控制台资源

交互和自助服务系列按设计始终可用——不能要求被锁定在账户之外的用户等待功能开关。控制台也始终可用，即使 /mcp 受功能开关控制：关闭 MCP 不应连带关闭控制台。

管理

服务器管理自身。GET /admin 是用于管理项目、团队、OAuth 客户端、管理员、终端用户、上游身份提供商、设置、签名密钥和仅追加审计跟踪的控制台。管理员通过针对本服务器自身签发方的 OpenID Connect 流程登录，因此无需维护第二套密码库。

### 从 AI Agent 进行管理（MCP）

同一管理 API 也可通过 Model Context Protocol 提供给 AI Agent，作为此服务器受 OAuth 2.1 保护的资源。该功能默认关闭——它会赋予 Agent 授权者的管理员权限，因此部署时应审慎开启：

1. 在控制台中，选择 Settings → Administration → Enable the administrative MCP control plane（保存后立即生效）。
2. 将 MCP 客户端指向 https://your-server/mcp，客户端 ID 为 admin-mcp，资源为 https://your-server/mcp。

之后，Agent 将以登录用户的管理员身份执行操作，且权限与该账号完全相同。它进行的每项更改都会经过与控制台相同的路由、检查和审计流程，每条审计记录都会注明操作员和 Agent。

有几项操作是明确禁止的：删除项目或团队、清空故障存储，以及更改哪些客户端身份可以管理此实例。删除操作会销毁容器，导致之后无从检查；最后一项则可能导致权限提升，因此这些操作仅限在控制台中进行。 其他破坏性操作都需要两步完成——Agent 先说明将要进行的更改，然后由你确认该项操作。

可在此使用的客户端身份。 上述保留的 client_id 始终可用，除开启开关外无需进行其他设置。无法指定 client_id 的 Agent 主机也可以使用此接口，前提是它通过OAuth 客户端 ID 元数据文档标识自身——即一个用于命名文档的 HTTPS URL，该文档会描述此客户端——并且超级管理员已在控制台的 Agent access 下添加该身份。通过动态客户端注册自行注册的客户端，无论如何配置都无法管理此实例：其身份由提出请求的一方按需生成，因此操作员无法对其进行有意义的允许列表设置。

保护你自己的 MCP 服务

同一协议接口也适用于非本服务的 MCP 服务。将其声明为项目的受保护资源——包括其规范 URI、所识别的作用域以及令牌的验证方式——此服务便会签发受众与该资源完全一致的令牌，无需修改此处的代码，也无需重启。Agent 主机会发现该服务，为你的最终用户完成登录，然后携带令牌返回；你的 MCP 服务可根据其颁发者元数据中指定的 jwks_uri 验证该令牌，无需询问任何信息。

使用 OAuth 保护你的 MCP 服务将端到端介绍整个流程——包括正确的拒绝响应应是什么样，让你能够区分“已受保护”和“尚未访问”。

已实现的标准

Flag 列标明该功能所受的标志控制；— 表示始终启用。默认设置请参阅功能。

规范	描述	标志
OAuth 2.1	目标配置：所有客户端均使用 PKCE、精确匹配重定向 URI、刷新令牌轮换，不使用隐式授权或 ROPC	—
RFC 6749	OAuth 2.0 授权框架	—
RFC 7636	PKCE	—
RFC 7519	JSON Web Token（JWT）	—
RFC 7517	JSON Web Key（JWK）	—
RFC 9068	OAuth 2.0 访问令牌的 JWT 配置文件	—
OIDC Core 1.0	OpenID Connect Core	—
OIDC Discovery 1.0	OpenID Connect Discovery	—
OIDC RP-Initiated Logout 1.0	客户端启动注销，并将用户带回	rpInitiatedLogout.enabled
OIDC Back-Channel Logout 1.0	通过服务到服务的方式通知客户端用户已注销，并接收上游提供方的注销通知	backchannelLogout.enabled、federation.enabled
RFC 8414	OAuth 2.0 授权服务器元数据	—
RFC 9207	授权服务器颁发者标识	—
RFC 8707	资源指示符	resourceIndicators.enabled
RFC 7009	OAuth 2.0 令牌撤销	revocation.enabled
RFC 7662	OAuth 2.0 令牌内省	introspection.enabled
RFC 9701	OAuth 令牌内省的 JWT 响应	jwtIntrospection.enabled
RFC 9126	推送授权请求（PAR）	par.enabled
RFC 9449	DPoP，包括随机数	dpop.enabled
RFC 7591	动态客户端注册	registration.enabled
RFC 7592	动态客户端注册管理	registrationManagement.enabled
RFC 8628	设备授权授权类型	deviceFlow.enabled
RFC 7523	JWT bearer 授权授权类型，已提交至 draft-ietf-oauth-rfc7523bis；也支持 jwt-dpop	jwtBearer.enabled
RFC 8693	令牌交换，采用 ID-JAG 配置文件	tokenExchange.enabled
ID-JAG	身份断言 JWT 授权授权类型（-04），支持两种角色：MCP 企业管理式授权	jwtBearer.enabled、tokenExchange.enabled
RFC 8705	mTLS 客户端身份验证和证书绑定令牌	mTLS.enabled
RFC 9396	丰富授权请求	richAuthorizationRequests.enabled
RFC 9728	OAuth 2.0 受保护资源元数据	mcp.enabled
RFC 7643	SCIM 核心架构	scim.enabled
RFC 7644	SCIM 协议	scim.enabled
CIBA	客户端发起的后端通道身份验证	ciba.enabled
JARM	JWT 安全授权响应模式	responseMode.jwt.enabled
RFC 6238	TOTP 第二因素	—
客户端 ID 元数据文档	通过客户端托管文档的 URL 标识客户端	clientIdMetadataDocument.enabled

安全

请通过 [email protected] 或私密漏洞报告报告漏洞； SECURITY.md 说明了范围、响应时间和免责条款。

同一文件还说明了代码背后的安全措施：已发布的 威胁模型、每次推送和每周进行的 CodeQL、依赖项和容器 扫描（运行内容及查看位置）、 带有 SBOM 和构建来源证明的签名镜像， 以及 OpenSSF Scorecard。 它还说明了目前尚不存在的事项——没有外部审计、没有付费漏洞赏金计划、没有 OpenID Foundation 认证——因为只列出好消息的安全页面并不值得信任。

贡献

问题和想法请前往 GitHub Discussions： 如何操作类问题请发到 Q&A，提案请发到 Ideas。

欢迎贡献！请提交 issue 或 pull request。对于重大变更，请先提交 issue 讨论提案。

许可证

OAuth-server.ts 使用 Functional Source License, Version 1.1, ALv2 Future License（FSL-1.1-ALv2）授权——与 Sentry 使用的许可证相同。简而言之：您可以出于任何目的使用、修改、 自行托管并再分发，但不得将其作为具有竞争性的托管服务提供给他人；每个版本会在发布两年后转换为 Apache License 2.0。

本项目于 2025 年 4 月作为 Filip Skokan 开发的 node-oidc-provider 的分支项目启动，原项目采用 MIT License 分发。其声明保留在 NOTICE 中。