API 參考

本頁完全由版本化的 OpenAPI 文件產生，沒有手寫的端點說明。 契約版本 1.0.0-draft，base URL https://api.lightup.tech/v1。

操作一覽

POST https://auth.lightup.tech/oauth2/token

operationId issueToken　能力 不需要（這裡是取得 token 的地方）

這個端點不在 API host 上。 完整網址就是上面那一個，沒有 /v1 前綴。

換取 access token。不需要 Bearer token（這是取得 token 的地方）， client 自己的認證放在表單或 Basic 標頭裡。

v1 支援的 grant

client_credentials 尚未實作：今天 /oauth2/token 只認 authorization_code 與 refresh_token，discovery 也只公告這兩個。這裡先寫下契約（ADR-004 D3）。

client 認證方式

client_secret_post（放表單，如下方 schema）或 client_secret_basic （Authorization: Basic base64(client_id:client_secret)）。public client 兩者都不用，只靠 PKCE。

不會回什麼

• client_credentials 不回 refresh_token（機器到期直接再換一張，ADR-004 D3）
• 不回 id_token 給資源存取用。就算流程拿到 id_token，它只能用來驗身分； 拿去打 API 會被擋（typ 不是 at+jwt）

冪等與重試

authorization_code 與 refresh_token 都是一次性的。 重送同一個 code 或已消耗的 refresh_token 會得到 invalid_grant，而且重放 refresh 會殺掉整個 token family（嚴格 rotation，第三方不放寬）。 逾時後不要盲目重試——重新走一次流程。client_credentials 沒有這個問題， 可以安全重試。

限流

這個端點有自己的限流，與 API 的 tenant／account 雙層限流分開。 超過回 429，看 Retry-After。

請求 body

application/x-www-form-urlencoded，schema TokenRequest，必填。

範例 clientCredentials — 機器：client_credentials

{
  "grant_type": "client_credentials",
  "client_id": "tp_asiauni_rehab",
  "client_secret": "<機器憑證，不要寫進版本控制>",
  "scope": "lightup.person.read lightup.person.metadata.write"
}

範例 authorizationCode — 使用者：authorization_code + PKCE

{
  "grant_type": "authorization_code",
  "client_id": "tp_kidpro_parentapp",
  "code": "<授權流程回傳的一次性 code>",
  "code_verifier": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk",
  "redirect_uri": "https://app.example.com/callback"
}

範例 refreshToken — 使用者：續期

{
  "grant_type": "refresh_token",
  "client_id": "tp_kidpro_parentapp",
  "refresh_token": "<上一次拿到的 refresh token>"
}

回應

200 範例

範例 workload — client_credentials（無 refresh_token）

{
  "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "lightup.person.read lightup.person.metadata.write"
}

範例 self — authorization_code（有 refresh_token）

{
  "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "lightup.profile.self.read",
  "refresh_token": "v1.MnR..."
}

400 範例

範例 unsupported

{
  "error": "unsupported_grant_type",
  "error_description": "client_credentials is not enabled on this deployment"
}

範例 invalidScope

{
  "error": "invalid_scope",
  "error_description": "requested scope is not granted to this application"
}

GET /v1/me

operationId getMe　能力 lightup.profile.self.read

能力：lightup.profile.self.read（方案 L1 起）

回傳這張 token 自己的身分，不是任意人的資料。v1 有兩種 profile：

機器 token 呼叫這支不會「變成某個使用者」：workload 的答案就是 service account 自己。機器能讀一群人的資料，不代表平台驗證過任何一位終端使用者 （計畫 §4.1）。

冪等：GET，天然冪等。不計入寫入額度。

回應

200 範例

範例 self — 使用者本人的 token

{
  "subjectType": "person",
  "subjectId": "psn_01j8m4k2r7e9v3xq5w8n0tza6b",
  "tenantId": "ten_0cqqg39h2199x8fd5kf58s0eb5",
  "clientId": "tp_kidpro_parentapp",
  "scopes": [
    "lightup.profile.self.read",
    "lightup.person.metadata.read"
  ],
  "actor": {
    "accountId": "acc_01j8m4k2r7e9v3xq5w8n0tzb7c"
  }
}

範例 workload — 機器 token

{
  "subjectType": "service_account",
  "subjectId": "acc_01j8m4k2r7e9v3xq5w8n0tzc8d",
  "tenantId": "ten_0cqqg39h2199x8fd5kf58s0eb5",
  "clientId": "tp_asiauni_rehab",
  "scopes": [
    "lightup.person.read",
    "lightup.person.metadata.write"
  ],
  "actor": {
    "accountId": "acc_01j8m4k2r7e9v3xq5w8n0tzc8d"
  }
}

GET /v1/tenant

operationId getTenant　能力 lightup.tenant.info.read

能力：lightup.tenant.info.read（方案 L1 起）

租戶由 token 決定，不由參數決定。沒有 GET /v1/tenants/{id}： 一張 token 只能看自己的租戶（計畫 §9 驗收矩陣第 1 列）。

回傳的是識別欄位，不是租戶設定。不含方案細節、聯絡人、網域設定、 社群 provider、LDAP 或任何秘密。

沒有 state 欄位（v1 刻意不給）

這支不回租戶的營運狀態。停權租戶不需要用一個欄位來表達： 它的 token 在簽發與每次判權兩處都已經被擋下，所以呼叫端 根本拿不到能成功呼叫的 token——狀態會以 401／403 的形式出現， 而不是以一個要自己判讀的欄位出現。

少一個欄位也少一種錯誤用法：如果 Gateway 在上游沒給值時填一個預設的 active，partner 會據此決定要不要送出寫入——那正是這種欄位最容易 造成的傷害。v1 的選擇是不給，而不是猜。

冪等：GET。

回應

200 範例

範例 default

{
  "tenantId": "ten_0cqqg39h2199x8fd5kf58s0eb5",
  "displayName": "KidPro"
}

GET /v1/persons/{personId}

operationId getPerson　能力 lightup.person.read

能力：lightup.person.read（方案 L2 起）

只回三個欄位：personId、displayName、createdAt。 沒有 email、沒有手機、沒有生日、沒有關係、沒有訂單、沒有任何 channel identity。 要更多欄位是新的能力，要新的 grant，不是在這裡加參數。

這支不回 metadata（計畫 §6：「一般主檔 GET 不順便吐出全部 metadata」）。 metadata 走 /v1/persons/{personId}/extensions/...，且需要另外的能力。

授權：除了 capability 之外，Amygdala 還會確認這個租戶對這個人有有效關係。 關係不成立時回 404，不是 403 —— caller 不應該從錯誤碼推斷這個 person 是否存在 （ADR-004 D9）。

冪等：GET。

參數

回應

200 範例

範例 default

{
  "personId": "psn_01j8m4k2r7e9v3xq5w8n0tza6b",
  "displayName": "王小明",
  "createdAt": "2025-03-11T02:14:07Z"
}

GET /v1/persons/{personId}/extensions

operationId listPersonExtensions　能力 lightup.person.metadata.read

能力：lightup.person.metadata.read（方案 L2 起）

只列出呼叫端自己擁有的 extension。 同租戶的別的 app 寫的 extension 不會出現在這裡，也不會被計入 total（計畫 §9 驗收矩陣第 2 列）。

分頁是有界的：limit 預設 20、上限 100。用 cursor 取下一頁。 沒有「全部拉下來」的參數，也沒有任意 JSON 查詢（計畫 §6：v1 只有 key lookup ＋ 有界分頁）。

冪等：GET。

參數

回應

200 範例

範例 default

{
  "items": [
    {
      "extensionId": "rehab_progress",
      "schemaVersion": 3,
      "etag": "\"17\"",
      "updatedAt": "2026-09-20T08:31:55Z",
      "updatedBy": "tp_asiauni_rehab"
    }
  ],
  "nextCursor": null
}

GET /v1/persons/{personId}/extensions/{extensionId}

operationId getPersonExtension　能力 lightup.person.metadata.read

能力：lightup.person.metadata.read（方案 L2 起）

回應帶 ETag。要改這筆資料，把 ETag 原封不動放進 If-Match。

404 的三種情況回答一樣：extension 未登記、這個 app 不是它的 owner、 資料不存在。錯誤碼不透露資源是否存在（ADR-004 D9）。

冪等：GET。

參數

回應

200 範例

範例 default

{
  "extensionId": "rehab_progress",
  "personId": "psn_01j8m4k2r7e9v3xq5w8n0tza6b",
  "schemaVersion": 3,
  "etag": "\"17\"",
  "data": {
    "lastSessionAt": "2026-09-19T09:00:00Z",
    "completedUnits": 12
  },
  "createdAt": "2026-04-02T01:00:00Z",
  "updatedAt": "2026-09-20T08:31:55Z",
  "updatedBy": "tp_asiauni_rehab"
}

PUT /v1/persons/{personId}/extensions/{extensionId}

operationId putPersonExtension　能力 lightup.person.metadata.write

能力：lightup.person.metadata.write（方案 L2 起）

整筆取代，不是 patch：data 就是新的完整內容。

並行控制（必讀）

每個 PUT 必須恰好帶一個前置條件標頭，而且是 RFC 9110 的標準語意， 沒有自訂延伸：

• 建立用 If-None-Match: * — 「只有在它還不存在時才寫」（RFC 9110 §13.1.2）
• 更新用 If-Match: "<etag>" — 「只有在它還是這一版時才寫」（§13.1.1）

If-Match 不接受 *（那是 DELETE 才有的用法）。兩個都不帶、或兩個 都帶，一律 428 precondition_required——本 API 沒有「無條件覆寫」這個操作， 因為那正是遺失更新的來源。

兩個 client 同時寫，後到的那個會拿到 409，不會覆蓋前一個（計畫 §6）。 正確處理方式：重新 GET、合併、帶新的 ETag 重送。

ℹ️ 為什麼建立衝突是 409 而不是 412。 RFC 9110 對失敗的前置條件給的是 412；本 API 刻意把它收斂成 409，讓「你和別人撞上了」只有一個狀態碼， client 的錯誤處理只要分辨 Problem.error（already_exists vs revision_conflict）就夠，不必同時處理 409 與 412 兩條路徑。 428 則保留給「你根本沒表明意圖」，那是 client 的 bug，不是衝突。

額度（計畫 §6／§7）

額度判定與寫入在同一交易內完成，所以大量並行寫入不會衝破上限 （計畫 §7「交易內處理並行寫入的額度競爭」）。 額度滿不會刪任何既有資料；讀取與刪除照常可用。

這裡不能放什麼

照片、逐題事件、無界成長的列表，以及任何被當成 permission、餘額、購買權益 或身份綁定的欄位（計畫 §6）。平台不會因為 metadata 說了什麼而授予任何權限。

冪等

同樣的 data ＋ 同樣的 If-Match 重送：第一次成功後 ETag 就變了， 第二次會得到 409。要安全重試，重讀後再送。 計量以 x-request-id 為 idempotency key，重試不重複計量。

參數

請求 body

application/json，schema PersonExtensionWrite，必填。

範例 default

{
  "schemaVersion": 3,
  "data": {
    "lastSessionAt": "2026-09-22T09:00:00Z",
    "completedUnits": 13
  }
}

回應

DELETE /v1/persons/{personId}/extensions/{extensionId}

operationId deletePersonExtension　能力 lightup.person.metadata.write

能力：lightup.person.metadata.write（方案 L2 起）

冪等：已經不存在也回 204（計畫 §6「刪除可冪等」）。

If-Match 必填（required: true，schema 驗得到）：

• If-Match: "<etag>" — 只在還是那一版時才刪。版本不符 → 409 revision_conflict
• If-Match: * — 不管哪一版都刪（RFC 9110 §13.1.1 的標準 * 語意： 「只要它存在」。這裡合用，因為刪除本來就只對存在的東西有意義）
• 省略 → 428 precondition_required

「已經不存在」與「存在但版本不符」不同：前者 204（冪等），後者 409。 DELETE 不看 If-None-Match；送了會被忽略。

刪除釋放筆數額度，但不會回填任何歷史；要保留請先匯出。

參數

回應

共用錯誤回應

Unauthorized

401 — token 本身不可用：沒帶、無效、過期、簽章錯、aud／iss／typ 不符 （例如把 ID token 或第一方 token 拿來用）。

error 一律是 invalid_token，不細分。 沒帶 token 與帶了壞 token 回同一個答案，aud 錯與簽章錯也回同一個答案——細分等於幫呼叫端 （包括攻擊者）確認哪一項才是錯的。真正的原因記在伺服器端， 用 x-request-id 查。

重新取得 token 再試。重試同一張 token 不會變成成功。

ℹ️ delegated 與 shared profile 的 token 不在這裡被擋：它們的簽章 是對的，會走完驗證再由授權決定拒絕，所以拿到的是 403 profile_not_supported。

範例 idTokenUsed — 拿 ID token 當 access token

{
  "error": "invalid_token",
  "message": "token is not an access token",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh2j"
}

Forbidden

403 — token 有效，但現在不准做這件事。重試不會變成允許—— 要改的是 grant、方案或請求本身。

error 是穩定代碼，逐字來自 Amygdala 的授權決定（ADR-004 D5）。 程式判斷用它，不要 parse message。

⚠️ tenant_mismatch 與 no_relationship 打在 person 資源上時會變成 404， 不是 403——否則 403 與 404 的差別本身就是一支「這個 person 存不存在」的 探測器（ADR-004 D9）。不透露資源是否存在是刻意的。

ℹ️ tenant_suspended 不折成 404，即使打在 person 資源上也一樣回 403。 它講的是你的租戶的狀態，不是目標資源存不存在，所以據此推不出 任何關於那個 person 的事——沒有要遮蔽的東西。

範例 missingCapability

{
  "error": "capability_not_granted",
  "message": "this application is not granted lightup.person.metadata.write",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh3k"
}

範例 planTooLow

{
  "error": "plan_capability_excluded",
  "message": "the tenant plan does not include this capability",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh4m"
}

NotFound

404 — 資源不存在，或存在但呼叫端連它存不存在都不該知道。 兩者刻意回同一個答案（ADR-004 D9）。

範例 default

{
  "error": "not_found",
  "message": "resource not found",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh5n"
}

Conflict

409 — 你和別人撞上了。沒有任何東西被寫入。 兩種：

• revision_conflict — 送出的 If-Match 與現行 ETag 不符（有人搶先寫了）。 重新 GET、合併、帶新的 ETag 重送。
• already_exists — 送了 If-None-Match: * 要建立，但它已經存在。 改成 GET 讀出現行 ETag，再用 If-Match 更新。

本 API 用 409 表達所有衝突，不用 412。 RFC 9110 對失敗的前置條件 給的是 412；收斂成單一狀態碼讓 client 只要分辨 Problem.error 就夠。 「前置條件標頭根本沒帶或帶重複」不是衝突，是 428，見下。

範例 conflict

{
  "error": "revision_conflict",
  "message": "the resource was modified; re-read and retry",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh6p"
}

範例 alreadyExists

{
  "error": "already_exists",
  "message": "the extension already exists; read its ETag and use If-Match",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh7q"
}

PreconditionRequired

428 — 這個寫入沒有表明它的前置條件（RFC 6585 §3）。

PUT 必須恰好帶一個：If-Match: "<etag>"（更新）或 If-None-Match: *（建立）。DELETE 必須帶 If-Match。 兩個都沒帶、或 PUT 同時帶兩個，就是這個錯誤。

沒有任何東西被寫入，而且重試同樣的請求永遠是同樣的結果—— 這是 client 的 bug，不是暫時狀況。本 API 沒有無條件覆寫的操作： 那正是遺失更新的來源（計畫 §6）。

範例 missing — 兩個都沒帶

{
  "error": "precondition_required",
  "message": "provide exactly one of If-Match or If-None-Match",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh7q"
}

範例 both — 兩個都帶

{
  "error": "precondition_required",
  "message": "If-Match and If-None-Match are mutually exclusive",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh8r"
}

PayloadTooLarge

413 — 單筆 data 超過 16 KiB。縮小內容，或把大東西放在你自己的資料庫 （計畫 §6：平台 metadata 不存照片與無界列表）。

範例 default

{
  "error": "payload_too_large",
  "message": "extension data exceeds 16 KiB",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh8r"
}

UnprocessableEntity

422 — 請求格式對，但內容不可接受：額度用盡、參數超界、schema 不符。

額度用盡不會刪任何資料。 既有資料照常可讀、可刪、可匯出。

範例 quota

{
  "error": "quota_exceeded",
  "message": "tenant reached 50000 records for this extension",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzh9s"
}

範例 schema

{
  "error": "schema_invalid",
  "message": "data does not match the registered extension schema",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzj1t"
}

TooManyRequests

429 — 限流。限流有兩層：tenant 與 service account／使用者 （計畫 §7）。兩層都可能觸發，回應不會告訴你是哪一層。

看 Retry-After 再重試。合法的大量同步不會被丟棄，會被要求放慢 ——需要更高額度請升級方案，別用更多帳號繞過（那會在 tenant 層再撞一次）。

範例 default

{
  "error": "rate_limited",
  "message": "too many requests",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzj2u"
}

AuthorizationUnavailable

503 — 平台現在無法判斷你有沒有權限。兩種，分開是因為要修的地方不同：

兩者都不是拒絕。平台 fail-closed：判不了就不放行，而不是降級成只驗簽 （計畫 §5）。都可以重試，請用指數退避；Retry-After 是建議不是承諾。

403 和 503 永遠不會長得一樣：前者是「不准」，後者是「現在不知道」。

範例 default

{
  "error": "authorization_unavailable",
  "message": "authorization service temporarily unavailable; retry",
  "requestId": "req_01j8m4k2r7e9v3xq5w8n0tzj3v"
}

Schema

TokenRequest

application/x-www-form-urlencoded。三種 grant 各自需要的欄位不同， 所以用 oneOf 分開——送錯組合在 schema 層就看得出來，不必等伺服器回 400。

型別 —。

ClientCredentialsRequest

機器／背景。得到 workload token，沒有 refresh_token。 client_secret 可改放 Authorization: Basic；兩種擇一，不要同時送。

未列出的欄位不被接受（additionalProperties: false）。

AuthorizationCodeRequest

使用者授權完成後，用一次性 code 換 token。得到 self token。 PKCE 必填——第三方 public 與 confidential client 都要。

未列出的欄位不被接受（additionalProperties: false）。

RefreshTokenRequest

續期使用者 token。嚴格 rotation：每次成功都會換一張新的 refresh token，舊的立即失效；重放已消耗的那一張會殺掉整個 family （第三方不適用任何放寬，見 ADR-004 D1）。

未列出的欄位不被接受（additionalProperties: false）。

ClientId

第三方 client id，形狀 tp_<tenant label>_<slug>，由 amygdala 配發。

型別 string。pattern ^tp_[a-z0-9]+(?:-[a-z0-9]+)*_[a-z0-9]+(?:-[a-z0-9]+)*$

ScopeString

以空白分隔的能力清單（OAuth 慣例，不是逗號）。 實際拿到的 scope 是各層交集後的結果，可能比請求的少—— 以回應的 scope 欄位為準，不要假設拿到的就是送出去的。

型別 string。

TokenResponse

RFC 6749 §5.1 的 token 回應。

未列出的欄位不被接受（additionalProperties: false）。

TokenError

RFC 6749 §5.2 的錯誤形狀。與本 API 其他端點的 Problem 不同—— 那是 OAuth 的既有契約，刻意保持原樣，不要把兩者混在同一個解析路徑。

未列出的欄位不被接受（additionalProperties: false）。

Problem

所有錯誤共用的形狀（RFC 9457 的精神，欄位刻意極簡）。 error 是穩定代碼，程式判斷請用它；message 是給人看的，隨時可能改字。

未列出的欄位不被接受（additionalProperties: false）。

PersonTypeId

型別 string。pattern ^psn_[0-9a-hjkmnp-tv-z]{26}$

TenantTypeId

型別 string。pattern ^ten_[0-9a-hjkmnp-tv-z]{26}$

ExtensionId

型別 string。pattern ^[a-z][a-z0-9_]{2,63}$

Capability

能力 id。完整清單是版本化的能力目錄（crates/lightup-types/capabilities.toml）， 對外由文件網站發布，每項標明說明、資源型別、最低方案等級與可用狀態 （planned / preview / ga）。v1 的五項全部是 preview。

型別 string。pattern ^lightup\.[a-z][a-z0-9.]*$

Me

這張 token 代表誰。

未列出的欄位不被接受（additionalProperties: false）。

Tenant

租戶的公開識別欄位。只有「這是誰」，沒有「它現在怎麼樣」。 不含租戶設定、方案等級、聯絡人、網域設定、社群 provider、LDAP， 也不含營運狀態（見下）。additionalProperties: false—— 內部欄位（例如 amygdala 的 slug）不會出現在這裡。

未列出的欄位不被接受（additionalProperties: false）。

Person

最少欄位。要更多欄位是新的能力與新的 grant，不是在這裡加參數。

未列出的欄位不被接受（additionalProperties: false）。

PersonExtensionWrite

寫入內容。data 整筆取代。 不要放照片、逐題事件、無界列表，或任何被當成權限／餘額／權益／身份綁定的欄位。

未列出的欄位不被接受（additionalProperties: false）。

PersonExtension

未列出的欄位不被接受（additionalProperties: false）。

PersonExtensionSummary

列表用的摘要，不含 data。要內容請用 key lookup 逐筆取。

未列出的欄位不被接受（additionalProperties: false）。

PersonExtensionPage

未列出的欄位不被接受（additionalProperties: false）。

安全機制

bearerAuth

LightUp profile-v2 access token。Authorization: Bearer <token>。

Gateway 驗這些，缺一不可：

• 簽章 ES256，key 取自固定 JWKS https://auth.lightup.tech/.well-known/jwks.json
• iss 是平台 issuer（不依 token 自報的 iss 去別處取 key）
• aud = lightup-api
• JOSE header typ = at+jwt → ID token 在這裡就被擋掉
• profile ∈ {self, workload} — v1 只有這兩種；delegated 與 shared 一律拒
• 未過期

用錯 token（ID token、第一方 storefront token、內部 x-system-token）一律 401。

oauth2AuthorizationCode

使用者授權（互動式）。public client 強制 PKCE S256； 第三方 confidential client 也必填 PKCE（不吃第一方的相容路徑）。

發出的 token 是 profile v2 self——代表登入的本人，而且只有本人。 v1 不簽發代理（delegated）token，同意頁也沒有「選擇被代理對象」這一步。 refresh 走嚴格 rotation：重放已消耗的 refresh 會殺掉整個 family。 第三方不會拿到 reuse grace、sliding 或 absolute-max 放寬。

flow authorizationCode

• authorizationUrl: https://auth.lightup.tech/oauth2/authorize
• tokenUrl: https://auth.lightup.tech/oauth2/token
• refreshUrl: https://auth.lightup.tech/oauth2/token

oauth2ClientCredentials

機器／背景操作。主體是 service account，不是 client： client 憑證證明「哪支程式」，token 的 sub 是租戶的 service account （acc_…，AccountKind::Service——與人使用同一個 id 前綴）。

發出的 token 是 profile v2 workload，TTL 15 分，沒有 refresh （到期就重新換一張）。

實際 scope = 請求的 scope ∩ service account 的 grantedCapabilities ∩ 租戶方案上限。交集為空 → invalid_scope，不會發一張沒有 scope 的 token。

憑證輪替：建立 next secret → 兩把並存最長 7 天 → promote，舊的立即失效。 撤銷：停用帳號或推進 epoch，在途 token 在下一個請求即失效。

⚠️ client_credentials 尚未在 /oauth2/token 實作，discovery 目前也沒有公告 （ADR-004 D3 是要做的事，不是現況）。

flow clientCredentials

• tokenUrl: https://auth.lightup.tech/oauth2/token