登入成功了，系統卻不認得你：Claude Code 2.1.312 新增的身分欄位，五個問答看懂

先把背景補上。2026 年 10 月 27 日，APPI News 刊出一篇分析，指向 Anthropic 在 Claude Code 2.1.312 發行紀錄中新增的 Claude apps gateway 設定項 oidc.user_id_claim。這個欄位讓閘道可以改用 ID token 裡 sub 以外的欄位辨識登入者，發行紀錄舉的例子是 Microsoft Entra ID 的 oid。

看起來只是版本清單裡的一行字，但對管過企業單一登入的人來說，這一行牽動的是「這個登入者到底對應到哪個帳號」。以下用問答把可確認的事實和需要自行查證的部分分開。

問一：這次到底改了什麼？

可確認的部分：Claude apps gateway 新增了 oidc.user_id_claim，讓閘道選用 ID token 中 sub 以外的 claim 作為使用者識別依據，發行紀錄以 Microsoft Entra ID 的 oid 為例。

同樣可確認的是，公開資訊到此為止。發行紀錄沒有列出設定檔位置、格式、預設值或部署限制。所以在官方設定文件補上細節之前，任何照著欄位名稱猜出來的設定片段都不該直接上線，先在測試環境驗過再說。

問二：為什麼 sub 不夠用？

OIDC Core 規格的設計是 sub 要跟 iss（發行者）合用，在單一發行者範圍內對特定使用者維持唯一且不重新分配。問題出在規格也允許成對識別碼（pairwise subject）：同一個使用者在不同應用程式可以拿到不同的 sub，用意是降低服務之間互相追蹤的可能。

Microsoft 的文件給了一個具體情境：同一位使用者用兩個不同應用程式登入時，兩邊拿到的 sub 可以不同，oid 則相同。如果組織的帳號目錄本來就以目錄物件 ID 綁定員工，閘道卻只讀得到另一種識別值，映射層又沒有轉換規則，系統就找不到對應帳號。

問三：sub、oid、email，實際選哪個？

把三個欄位的特性並排看：

• sub 加 iss：規格保證的穩定唯一組合，預設的可靠選擇。
• oid：在 Microsoft Entra ID 的同一租戶內，跨應用程式識別同一使用者。適合需要跨應用對應的情境，選用前仍要確認 token 真的包含它。
• email：可能變更，也可能重複，原文明確提醒不宜當授權依據。

還有一個反向原則：如果現有政策用 sub 已經正確映射，沒有必要只為了改用 oid 而動設定。

問四：升級前要核對哪些事？

原文建議把三件事分開驗收：登入驗證確認帳號通過身分提供者檢查，閘道識別決定登入者對應哪筆使用者資料，授權才依角色與政策決定可存取的功能。串接失敗時，只看登入頁成功與否看不出問題。

盤點可以從實際流程下手：閘道收到哪個 issuer 的 token、目前用哪個 claim 建立使用者記錄、授權系統用哪個鍵查角色、日誌以什麼值串起登入事件。映射對不上時的可能結果包括找不到使用者、稽核紀錄分散在不同帳號，或把新舊帳號誤當同一人。要強調的是，這些是整合檢查的常見情境，發行紀錄本身並沒有宣稱這次更新造成過這類故障。

這種「升級前先核對、升級後分開驗收」的節奏，其實跟 llama.cpp 跳版前先別急著信的驗收三步是同一套思路：版本清單寫得再清楚，相容性條件還是得自己對過一遍。

問五：這次更新會自動改變權限嗎？

不會。原文特別指出，這是閘道身分對接的調整，回答的是「用哪個值找出使用者」，還沒回答「使用者可以做什麼」。後者仍由組織既有的角色、羣組、政策與整合設定決定。登入成功不代表角色與權限自動同步，這兩段流程要分開驗。

總結可確認的範圍：一個新欄位、一個 oid 例子、以及選擇識別欄位時的幾個判準。至於設定檔怎麼寫、哪些 gateway 版本支援，得等正式文件或測試環境給答案。