工位預訂的 SSO、通行金鑰與雙重驗證登入

想像一下 Kasia，一家剛轉為混合辦公、180 人公司裡唯一的 IT 人員。星期一上午 8:40，已經有三張工單在等著：一位同事忘了工位預訂工具的密碼，另一位找不到寄有登入驗證碼的郵件，還有一位團隊主管問，星期五離職的約聘人員是否仍能預訂停車位。Kasia 花了兩年時間，把每個應用程式都放到公司的身分識別提供者後面。工位預訂工具是唯一還有自己一套密碼的。

以下說明 Desk & Park 的登入如何運作、Kasia 會設定什麼，以及產品刻意打破「一切都走 SSO」原則的那個地方。所有這些功能都適用於每個方案，包括免費的 Start 方案。

步驟 1：連接身分識別提供者（透過 OpenID Connect 的 SSO）

Desk & Park 透過 OpenID Connect 支援單一登入，這是 Microsoft Entra ID、Google Workspace、Okta 以及大多數其他身分識別提供者都使用的標準。流程為搭配 PKCE 的授權碼流程，也就是建議 Web 應用程式採用的方式。

Kasia 打開 組織設定 → 單一登入 (SSO)，填寫四個欄位：

簽發者 URL：Google 為 https://accounts.google.com，Entra 為 https://login.microsoftonline.com/<tenant-id>/v2.0，或任何其他 OIDC 提供者的簽發者。
用戶端 ID 與 用戶端密碼，來自她在提供者主控台中建立的應用程式註冊。密碼會加密儲存，且不會再次顯示；若要變更，她得輸入新的密碼。
允許的電子郵件網域（選填）。設定後，只有該網域的地址才能使用 SSO 登入，因此剛好存在於提供者中的個人帳號無法進入。
卡片會顯示要貼回應用程式註冊中的 重新導向 URI。

她勾選 啟用 SSO 登入 並儲存。登入頁面現在會顯示 使用 SSO 登入，忘記密碼的同事便能使用和電子郵件相同的 Microsoft 或 Google 帳號登入。一個組織連接一個提供者。

SSO 本身不做的事：建立帳號

第一次 SSO 登入不會建立帳號。若有人在提供者端驗證成功，卻沒有 Desk & Park 帳號，會被送回登入頁面，並看到請他向管理員索取邀請的訊息。帳號由管理員建立：逐一邀請、從名單匯入，或透過 SCIM 從 Entra ID 或 Okta 自動佈建，相關說明請見〈以 Entra ID 與 Okta 進行 SCIM 佈建與離職處理〉。

這對 Kasia 的第三張工單很重要：在提供者端封鎖某人，只完成了離職處理的一半。另一半是停用 Desk & Park 帳號並結束其工作階段，而當此人在目錄中被停用時，SCIM 就會完成這件事。

SSO 登入時由誰檢查第二因素

有人以 SSO 登入時，身分識別提供者已經驗證過他了，所以 Desk & Park 不會再額外加上自己的驗證碼步驟。第二因素就是您的提供者所要求的那一個。如果您的 Entra 或 Okta 原則要求 MFA，員工經歷的就是那一道 MFA。

步驟 2：刻意的例外——管理員

這是讓部分 IT 團隊意外的地方：管理員帳號無法使用 SSO 登入。 這是刻意的。

SSO 登入是以電子郵件地址比對使用者。如果身分識別提供者某天設定錯誤或遭到入侵，控制它的人就可能出示管理員的電子郵件地址，直接走進預訂系統的管理主控台。為了關上這扇門，管理員使用平台本身的驗證因素：密碼、通行金鑰或電子郵件驗證碼，並在開啟雙重驗證後，再加上驗證器應用程式的代碼。

所以對 Kasia 而言，實務上的規則是：每個管理員帳號都應該在 設定 → 安全 中開啟雙重驗證，從她自己的帳號開始。產品並不強制，正因如此，這件事應該列在她的檢查清單上。

步驟 3：給討厭密碼的人用的通行金鑰

通行金鑰（WebAuthn）讓人用指紋、臉部辨識或裝置 PIN 碼登入，沒有需要記住、也不會被網路釣魚騙走的密碼。每位使用者在 設定 → 安全 → 通行金鑰 中自行新增（「新增通行金鑰」），也可以替它命名（「MacBook」、「iPhone」）。清單會顯示每把通行金鑰的新增時間與上次使用時間，任何一把都可以移除。

對資安審查很重要的一個細節：搭配使用者驗證（指紋、臉部或 PIN 碼檢查）使用的通行金鑰，本身就算作兩個因素，能直接完成登入。未搭配使用者驗證的通行金鑰，只被視為「持有」因素，所以開啟了雙重驗證的帳號，之後仍會進入驗證碼步驟。

步驟 4：以驗證器應用程式進行雙重驗證

Desk & Park 的雙重驗證採用 TOTP：驗證器應用程式中的六位數代碼。每位使用者在 設定 → 安全 中自行開啟；此後，每次以密碼、電子郵件驗證碼或未搭配使用者驗證的通行金鑰登入時，都會要求輸入代碼。

使用者也會拿到一次性復原碼：如果手機遺失，可用一組復原碼登入，用過即失效。復原碼可以重新產生，開啟或關閉雙重驗證也會記錄在安全性記錄中。

步驟 5：看得到、也能結束的工作階段

在 設定 → 安全 → 活動會話 中，每位使用者都能看到自己在哪些地方登入（瀏覽器、作業系統、IP 位址、開始時間），並可撤銷任何一個工作階段，或選擇 退出所有裝置。

在幕後，還有兩個機制默默運作：

更新權杖輪替。 每次工作階段更新時，舊權杖都會被替換。如果已使用過的權杖再次出現，這代表它被複製過，整個工作階段就會被結束。
重複失敗後鎖定。 多次嘗試失敗後，接下來的嘗試會被封鎖一段時間，鎖定事件也會出現在安全性記錄中。

導入的實用建議

從管理員開始。 在宣布 SSO 之前，先確認每位管理員都已開啟雙重驗證並新增通行金鑰。他們無法使用 SSO，所以他們自己的登入必須夠強。
設定允許的電子郵件網域，如果您的身分識別提供者中也有訪客或個人帳號。
決定帳號如何建立。 小型辦公室用邀請就夠了。規模再大一些，就連接 SCIM，讓到職與離職人員從目錄自動同步。
公告保持簡短。 「請用『使用 SSO 登入』，帳號和您的電子郵件相同」就夠了。
偶爾看看安全動態。 登入、失敗、鎖定和雙重驗證變更都會出現在管理員稽核日誌中；相關說明請見〈稽核日誌與支援存取透明度〉。

範圍：它不做什麼

為了讓期待保持誠實：單一登入只支援 OpenID Connect，所以沒有 SAML。沒有強制所有使用者開啟雙重驗證的全組織原則，沒有可設定的工作階段逾時，沒有 IP 允許清單，也沒有關閉其他登入方式的「僅限 SSO」模式。雙重驗證是每位使用者自己的選擇，這也是上面的檢查清單從管理員開始的原因。資料本身存放在哪裡是另一個主題，請見〈為什麼您的職場資料需要獨立的資料庫〉。

方案與限制請見價格頁面；整間辦公室的設定方式說明於導入指南。

常見問題

哪些身分識別提供者可以搭配 Desk & Park 的 SSO？

任何支援 OpenID Connect 的提供者，包括 Microsoft Entra ID、Google Workspace 和 Okta。一個組織連接一個提供者。不支援 SAML。

第一次 SSO 登入會自動建立帳號嗎？

不會。帳號必須先存在：由管理員邀請該人、匯入名單，或透過 SCIM 從 Entra ID 或 Okta 佈建帳號。沒有帳號的人會被送回登入頁面，並看到請他詢問管理員的訊息。

為什麼管理員不能用 SSO 登入？

因為 SSO 登入是以電子郵件比對帳號，而設定錯誤或遭入侵的身分識別提供者，絕不能有辦法打開管理主控台。管理員以密碼、通行金鑰或電子郵件驗證碼登入，開啟雙重驗證後再加上驗證器應用程式的代碼。

我們可以強制所有人使用雙重驗證嗎？

產品中無法做到。雙重驗證由每位使用者在「設定 → 安全」中自行開啟。以 SSO 登入的員工，會經過您的身分識別提供者所要求的 MFA；對管理員來說，開啟雙重驗證應列入您的設定檢查清單。

免費方案包含 SSO 嗎？

包含。SSO、通行金鑰、雙重驗證和使用中工作階段清單，適用於所有方案，包括 Start 方案。