近年來,越來越多企業重視 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: 又稱為成員目錄模式,是存在已久的登入協定,但使用非常廣泛,大多數軟體都能夠整合。
SGML: 稍微新一點的 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 這些服務了。也許傳統的企業要數位轉型會比較緩慢,這新興的數位原生企業,很可能一開始就會把 SSO 納入考量。
如果您建置的網站想要整合自家 SSO,或是您本身就想成為一個可用的 SSO 平台,以跟上數位發展的趨勢,夏木樂長年專精於替企業做認證系統的開發,歡迎尋找我們洽詢。