近年來，越來越多企業重視 SSO 單點登入，有的早就已經做好 SSO ，因此找夏木樂作網站時，希望能整合自家 SSO。也有的企業剛開始起步，詢問夏木樂能不能一起把 SSO 平台做起來。
今天夏木樂提供一個簡單的科普，介紹什麼是 SSO，以及企業網站運用 SSO 的多種方式。
SSO 是什麼?
SSO 全名為 Single Sign On，意思是多個登入端點，皆採用相同的認證管道。白話文來說，就是當企業有多個網站時，可以從一個統一的入口登入帳戶，接著就所有的網站都能使用。
這個概念其實在歐美已經行之有年，有許多大型上市櫃企業如 Okta、Auth0 就是在幫助企業建置 SSO 的服務。而在台灣，雖然討論度不高，但許多大專院校或公家單位，可能早早就在做了。假設您要發現在學校中要登入教務處、總務處、選課平台等等，都會掉跳到同一個登入畫面，輸入學號與密碼，就能使用，那麼便是有 SSO 平台了。
而在一般民眾日常生活中最常見的，莫過於 Google 或 Yahoo 這樣的多服務平台。你會發現無論要登入 Gmail、雲端硬碟還是 Youtube，都會導向到同一個 Google 登入頁面，而且在一個網站登入，其他網站也都自動登入了，這就是 SSO 的效果。
不只有網站，遊戲也常常做 SSO，常見的如 Ubisoft Connect、Battle.net、PlayStation Network 等等，都替自己旗下的遊戲建立了啟動器應用程式或網頁 SSO 介面，方便玩家們共用一個帳號來啟動自己買的所有遊戲。
不過單一登入口這也只是最好判斷的一種 SSO，實際上 SSO 還有很多模式。
SSO 的種類
前面提到，有單一登入頁面的，是常見的 SSO。但 SSO 並沒有規定一定要共用登入口，登入的網站也不限是企業自己，還是外部的服務網站。
以下情境都會被認為是 SSO:
一個組織單位內的網站與服務，都能用同一個帳號身分存取。
一個對外營運的網站，提供多種管道(網頁、手機app、桌面應用程式)，但都共用帳號與身分，或是共用登入口。
一個網站登入後，其他相關網站也都同時登入，登出時也一樣同步
我們接下來介紹幾種普遍被視為 SSO 的模式，你會發現可能早就存在生活周遭了。
共用帳密模式
如果多個網站各自有自己的登入界面，但是你依然可以用同一組帳密登入，也是 SSO 的一種，我們就曾經幫遠見一號課堂與龍騰愛玩課實作這種 SSO，可以與企業內部原有的會員互通。
這種模式採用的技術以以下幾種:
AD / LDAP: 又稱為成員目錄模式，是存在已久的登入協定，但使用非常廣泛，大多數軟體都能夠整合。
SAML: 稍微新一點的 SSO 串接模式，功能也很多，目前歐美軟體界主流採用這種模式。
客製化 API: 企業自行建立 Restful API 給其他廠商串接，是最有彈性的方式，但必須針對每個企業自行客製化。
OAuth / OIDC 社群登入
常見的 Google / Facebook / LINE 登入也屬於一種廣義的 SSO，假設網站本身不做會員系統，強制採用 Google 登入，就等於是把 Google 當成會員系統，很適合一些小型網站使用。
另外由於 Google Workspace 企業平台本身就具備員工帳號管理功能，有些公司會將 Google Workspace 當成自家的 SSO 平台，用 Google 社群登入或 SAML 功能來達成 SSO 效果。
也有企業自己在主站上建立了會員系統，然後開放成 OAuth 社群登入介面給其他網站串接，這也是 SSO 的一種方式。我們曾經替 AddMaker 與1號課堂實做過社群登入(OAuth)接口。
這種模式常用的協定有:
OAuth: 幾乎所有的社群登入都是採用 OAuth 作為底層的協定， OAuth 的特色就是第三方授權，讓擁有帳號的主網站，聽過使用者同意後，授權給第三方應用程式可以存取使用者資訊，這是當初 OAuth 被設計出來的主要原因。
OpenID Connect (OIDC): OIDC 是 OAuth 的用在身分存取上的附加協定，他其實是與 OAuth 協同運作的。OAuth 處理了認證與授權這件事，OIDC 則處理了如何取得使用者個人資料的部份的協定。
裝置認證流 (Device Flow)
有時候，你如果安裝一些如 Slack、Postman 等等的桌面應用軟體，登入時，他會打開瀏覽器視窗，請您在網頁畫面登入，登入完成後，他會跳回到應用程式，然後應用程式就完成登入了。這是 OAuth 的一種進階呈現，稱為 Device Flow。
Android TV 用 QRCode 導向手機 app 當作認證管道，也是 Device Flow 的一種
Device Flow 已經行之有年，但過去還沒有這麼普遍。直到 2019 年這項協定成為了 RFC 8628 標準並改名為 OAuth 2.0 Device Authorization Grant 後，變越來越普及，如今許多網站應用推出的桌面程式，幾乎都用這種方式與自家平台做 SSO 整合。
這種模式採用的協定為:
- OAuth 2.0 Device Authorization Grant: 由 RFC8628 標準所定義，主要規定了如何從應用程式打開瀏覽器認證，以及瀏覽器如何回呼應用程式的流程。
Machine 2 Machine (M2M)
Machine 2 Machine (M2M) 通常用在 IoT 智慧家庭或工業 4.0 環境，是指在沒有人工干預的情況下，兩個設備或機器能夠相互驗證彼此身份，並確保通訊的安全性。這通常通過使用 API 金鑰、憑證、OAuth 2.0 等技術實現。
也就是說，還是要有一台機器通過使用者登入認證，然後將允許串連的裝置設定好，這些裝置就能獲得授權，並且相互交換資訊。舉例來說，你先用手機登入某個 app 認證了身分，然後再用手機藍芽或 Wifi 連線智慧裝置，手機將你的認證資訊授權給那個裝置，於是該裝置也獲得授權可以使用你的資訊。Chromecast 與 Google Home 的連線是一個經典案例。
其他現實案例包含:
智慧家庭系統：智能燈泡、恒溫器、安防攝像頭等設備需要相互通訊。例如，當安防攝像頭偵測到異常活動時，會通知恒溫器降低溫度以節省能源。這些設備之間的通訊通過 M2M 認證來確保只有合法的設備才能參與互動，防止未經授權的訪問。
車聯網：現代汽車中的各種傳感器和系統需要實時通訊。例如，車輛的導航系統需要與交通管理系統通信以獲取最新的交通信息。這些通訊需要通過 M2M 認證來確保數據的準確性和安全性，避免潛在的安全隱患。
工業自動化：在自動化工廠中，各種機器和控制系統需要進行無縫通訊。例如，生產線上的機器人需要與中央控制系統交換數據，以確保生產流程的順暢運行。M2M 認證在這裡確保了每個機器和系統的數據交換是安全和可靠的。
第三方會員代管 SSO 平台
由於 SSO 為了安全考量，機制與協定越來越複雜，許多企業可能沒有能力自己打造完善的 SSO 平台，所以越來越多的軟體、應用程式改用第三方平台做為自己家的會員中心。
最簡單的案例就是整個網站只提供 Google / Fcebook 登入等，自己不做會員系統。另外近年流行的 IAM SaaS 平台如 Auth0、Corbado 等等，都可以讓網站應用程式直接採用他們的平台做為會員系統，甚至可以多網站共用 SSO 登入界面。最近非常紅的 OpenAI 就是用 Auth0 來做自家登入界面的:
遊戲界則早就行之有年，許多獨立遊戲，小型工作室等等，都會將 Steam 或是 PSN 做為自家遊戲的 SSO 登入口，這樣就不需要額外雇用網站工程師來打造登入界面。今年很紅的絕地戰兵2 (Helldivers 2) 就是採用 Steam 與 PSN 作為 SSO 登入口，並流暢的整合 PC / PS5 跨平台玩家同時上線共同遊玩。
除了以上模式以外，SSO 還有非常多種模式，可能無法用一篇文章簡單的帶過。接下來則要介紹一下企業導入 SSO 的好處。
企業導入 SSO 有什麼優點
企業導入 SSO 的優點非常多，包含以下優勢:
統一管理員工身分: 當員工越來越多，每天都有人到職與離職，這時候控管人員存取權就很重要，已經離職的員工，不應該保留登入權限。運用 SSO 就能很方便的移除離職員工的帳號。
統一設定安全規範: 假設企業要對員工設定帳號規範，例如密碼長度、強制兩階段驗證、裝置管理等等，都能統一用單一管理平台做到，無須每個平台設定一次。
集中式權限控管: 當企業有多個網站與系統時，IT 人員很難管控誰有權限使用那些系統。有時候，可能某人臨時要用某個網站，於是有權限的同事就直接開帳號給他，密碼可能也沒有照規定設定。運用 SSO 才能統一開放並管理權限。
行為監測: 有了中央 SSO 平台，員工登入或使用什麼平台都能立刻知道。可以避免未經允許的加班、存取等行為。如果員工帳號被盜了，在異常的時間與地理位置登入，資訊部門也能夠立刻掌握。
企業如何導入 SSO?
對中小企業來說，預算可能沒那麼充足，但不用擔心，像是 Google Workspace 就有提供 SAML 的整合功能，如果要使用的軟體與網站有支援 SAML SSO 的話，不妨就直接與 Google 平台做整合。
像 Slack 這類應用軟體的定價，都會說明什麼方案可以用 SSO，如果團隊有需要，就可以直接選擇該方案。
就算你們家企業沒有採用 Google Workspace，也是有很多替代方案，例如 Synology NAS 就有提供 SAML SSO Provider 的功能，可以讓外部網站把 NAS 當成會員認證管道。
真的都沒有用這些平台，但企業有在用微軟 AD 或 Linux LDAP，也是可以用 AD 協定當作 SSO 認證管道，或是採用自行開發 API 的方式，都是可考慮的解決方案。不過目前歐美的軟體大多只用 SAML 與 OAuth，所以遵循標準的話，也比較容易找到合適的應用軟體喔。
我們的公司或網站需要 SSO 嗎?
許多客戶找夏木樂作網站時，其實也很猶豫到底要不要把 SSO 做進去。
通常我們會提供一些判斷方式。假設您的網站只是形象網站，管理員通常只有行銷部門的兩三位小編日常上架資料。夏木樂認為，沒有必要做 SSO！
從資安的觀點來看，越多節點，其實就越脆弱。假設一個相對獨立的系統，擁有的資料只是企業對外宣傳的公開素材，不包含任何隱私資料，最好的方法就是讓他與企業內部系統越獨立越好。唯一要控管的是讓少數這些小編們具有資安意識，規範高強度密碼等等，避免帳號遭到盜用。
那什麼情況下很建議做 SSO 呢？
例如您的企業需要保留大量外部會員資料，這些會員都可能含有個資。或者您的網站經常有大量業務與銷售人員登入，查找客戶資料與訂單。由於這裡面牽涉到大量個資與企業營業秘密，通常會建議，要將個資集中在中央的會員中心控管。各別獨立網站應該只能在授權後取用必要的會員資訊，假設某個網站用不到電話地址，就不要傳輸到該網站。
我們也針對這類資安管理寫過文章，可以參考看看
結語: SSO 將成為新時代企業的標準
過去，人們習慣用紙上管理員工資訊，發送身分證讓員工通過檢查關卡。到了數位時代，則轉用 Excel 來管理員工資訊。
但在未來的數位原生時代，多企業剛建立時，就已經習慣使用 Google / Facebook / Slack 這些服務了。而如果是國外的 SaaS 公司，可能一開始就會考慮要串接 Auth0、Okta、Snowflare、Datadog、Sentry 等等專業服務廠商，這些都是台灣廠商較少接觸的的新興大型軟體平台。也許傳統的企業要數位轉型會比較緩慢，但新興的數位原生企業，很可能一開始就會把 SSO 納入考量。
如果您建置的網站想要整合自家 SSO，或是您本身就想成為一個可用的 SSO 平台，以跟上數位發展的趨勢，夏木樂長年專精於替企業做認證系統的開發，歡迎尋找我們洽詢。
