快速接入單點登入

中央授權中心 OAuth 2 快速接入

版本/日期：v2.1 / 2025-08-05
製作單位：中央授權中心開發維運團隊

目的

本講稿旨在讓開發人員快速掌握如何接入中央授權中心，實現單點登入 (SSO) 功能。
本次分享將以 Postman 工具，完整演示「OAuth 2.0 授權碼模式」的對接流程，但不涉及具體的程式碼編寫。

【TIPS】
1、「中央授權中心」是鴻海/富士康打造的統一身份平台，它整合了「相信帳號」、「eID 帳號」以及「外部賬號二次驗證」服務，為各類應用提供基於 OIDC、OAuth 2.0 等標準協議的單點登入與授權服務。同時也相容 SAML 2.0 等業界標準。
2、單點登入 (SSO) 和 API 授權 (Bearer Token) 是此平台的兩大核心功能。本次我們聚焦於前者，後者暫不涉及。

前期準備

一）客戶端申請信息填寫

進入中央授權中心 sso.foxconn.com 。
點擊進入「開發中心」使用相信掃碼等方式登錄。
登錄后點擊進入「我的申請單」> 「申請客戶端」。
填寫相關資料之后點擊「提交申請單」按鈕。

【TIPS】
1、協議類型選擇「OIDC協議服務」。
2、預設客戶端ID 申請成功之后不能修改。其余(客戶端)資料后續可修改。
3、請記住你填寫的密碼，以防不必要的麻煩。

前期準備

二）申請單承諾及簽核

提交申請：進入申請詳情頁。
掃碼簽名：申請人使用「相信APP」掃碼簽名。
發起簽核：簽名後填寫審核人資訊並發起流程。
申請人確認：申請人收到「相信」通知後，點擊確認。
審核人簽核：審核人收到「相信」通知，完成最終簽核。

注意：簽核除了收到「相信」通知後點擊處理，也可以直接在本網站「開發中心」> 「我的簽核」中處理。

按引導掃碼在相信APP完成承諾簽名

按引導填寫審核人信息完成簽核

前期準備

三）客戶端信息維護

申請單簽核完成待相信團隊作業完成之后，即可在網站「我的客戶端」中查看客戶端列表。
點擊「修改資料」按鈕，即可進入客戶端設定修改界面。
在此界面可以根據你的需要維護多個（允許）重定向URL。

Postman 調試

一）配置 Token

「Auth」選項卡中「Type」選擇「OAuth 2.0」。
填寫「Configure New Token」信息。
點擊「Get New Access Token」按鈕。
按引導界面使用相信掃碼完成身份驗證。

注意：Callback URL 需要填一個正確的（允許）重定向URL。

配置相信信息，并點擊右下側按鈕

Postman 調試

二）使用 Token 調用 userinfo 接口

身份驗證后得到Token點擊「Use Token」(如右圖)。

填寫請求地址 (如左圖)。
點擊「Send」按鈕，即完成請求。

查看 Postman 完整請求

點擊 Postman 左下方的 Console 選單，可看其完整的請求內容。

【TIPS】開發時需注意：
1、Code 用過即廢：授權碼 (code) 是一次性票據。
2、Redirect URI 須統一：兩次請求 (/authorize, /token) 的 redirect_uri 必須相同。
3、環境要求：需開通 443 端口，且支援 TLS 1.2+。
4、進階功能演示： 【內網對接演示】、【外網對接演示】，請任選一個參考。

補充說明：權限 (Scope) 與接入模式選擇

核心概念：Scope = 權限

您可以把 Scope 想像成一張飯店的房卡，它精確地定義了您「能做什麼」。

openid profile foxconn

ID Scope (驗證你是誰)
身份資源/ID Resources

civet.api.msg SaaS.api.vote

API Scope (你能存取什麼資源)
API資源/API Resources

場景一：使用者登入應用

適用情境：需要 真人使用者 登入的場景。
應選模式：授權碼模式 (Authorization Code)
核心特點：

使用者全程參與、同意授權
安全性最高
可獲得身份票據 (ID Token)與授權票據

Tips: 授權碼模式中 Scope 必須包含 openid。

場景二：後端服務呼叫

適用情境：後端服務間呼叫 無使用者 的M2M場景。
應選模式：客戶端模式 (Client Credentials)
核心特點：

應用程式代表自己驗證
流程簡單直接
僅獲得授權票據 (Access Token)

Tips: 客戶端模式中 Scope 不能包含任何 ID Scope。
API資源（API Scope）由集團各系統提供。

補充說明：關於 ClientId 的常見問題

一、ClientId 可否多個系統共用？

結論：強烈不建議

將 ClientId 視為應用程式在授權中心的唯一身分證。多個系統共用一把鑰匙會帶來嚴重問題：

安全性風險：任何一個共用系統的密鑰 (Client Secret) 洩漏，等同於所有系統的權限都洩漏了。
權限管理混亂：無法為單一系統做精確的權限控制（如：Scope、Callback URL）。
稽核追蹤困難：從授權中心的日誌中，無法分辨是哪個系統發起的請求。

原則：一個獨立的應用程式，就應對應一個獨立的 ClientId。

二、同系統多域名是否要申請多個 ClientId？

結論：不一定，視場景而定。

技術上，一個 ClientId 可以配置多個重定向 URL (Redirect URI)，以支援不同域名。

最佳實踐：建議為不同「環境」申請不同 ClientId。

開發/測試/生產環境分離：建議申請多個 ClientId (如 my-app-dev, my-app-prod )，做到徹底的環境隔離，配置更清晰、安全。
同一系統，多個正式別名：若正式環境可透過多個域名訪問，則可使用單一 ClientId 並配置多個對應的 Redirect URI。

Thanks

其它內容

「相信」整合開發流程快速接入單點登入 API資源交易配置說明 acr_values 參數說明內省端點與權杖驗證 OIDC接入需求規範書模板多因子驗證 - 流程圖說明中央授權中心OIDC支持說明系統更新歷程