快速瞭解 SSO 通訊協定，解決傳統身分驗證問題
在應用系統日益增多的時代，傳統身分認證機制的使用為終端使用者、組織帳號管理者、應用系統開發者帶來諸多的困擾，可能需記憶多組帳號密碼，產生資安上的問題…等。因此，透過資通電腦 uIAM 的單一簽入（SSO；Single Sign On）將可解決傳統身分認證機制帶來的不便與問題。現在馬上來瞭解一下單一簽入裡的通訊協定 OAuth 2.0 基本概念吧！
傳統身份認證機制的問題
傳統的身份驗證機制，是由每個應用系統各自維護使用者的帳號和密碼，這種架構隨著使用的應用系統和服務漸增，就會開始造成使用上的困擾。對應用系統的終端使用者來說，原本被迫記住各個應用系統上不同的帳號和密碼就已經是有口難言的苦差事，若再加上基於安全策略，應用系統各自選用了不同的強制密碼規則政策，且必須在一定週期強制做更換，新的密碼又往往被要求不得使用已使用過的密碼，如此一來，記住各個系統的密碼變得越來越艱鉅，也對使用者造成巨大的困擾。對組織內的使用者帳號管理人員來說，當使用者離開組織或角色發生變化時，所有應用系統上的帳號都必須進行一番調整，這項工作可謂是繁冗。然而對應用系統開發者來說，則是必須在各個應用系統不斷重複開發維護著原本與系統功能面毫無關係的身份授權認證功能。
單一簽入與常見的通訊協定
正如前述，傳統身份驗證機制本身存在著種種使用上的不方便。而單一簽入的身份認證解決方案則是為了解決這些問題而來。在單一簽入的身份認證架構之下，SSO 扮演所有應用系統之間唯一的身份認證中心，這個認證中心負責維護管理著唯一的一份帳號、密碼（當然還可以加入其他的身份識別因子）以及身份識別的任務，而終端使用者只需在 SSO 這個認證中心進行一次登入動作，其他的所有應用系統都可以透過與 SSO 驗證中心溝通以獲取該使用者的登入狀態，如此一來，即可免去前述的種種不便。
在單一簽入的概念模型中，扮演身份認證中心的角色我們稱之為 Identity Provider（簡稱 IDP），而應用系統扮演的角色則稱之為 Service Provider（簡稱 SP）。在技術上，必須發展出能支持 IDP 和 SP 之間溝通和傳遞交換使用者登入訊息的溝通機制，此一溝通機制我們稱之為通訊協定（protocol）。在 SSO 解決方案的通訊協定中，目前最廣為熟知和流行的有 OAuth 2.0 和 SAML 2.0 兩種。接下來，我們就來淺談一下 OAuth 2.0 的基本概念。
OAuth 2.0
下面這張圖是在 OAuth 2.0 的規格文件中，用來描述通訊協定的概念模型。我們用一個簡單的使用情境來說明會比較容易理解這個模型當中的各種角色。假設現在的情境是使用者透過雲端沖印網站，想要將自己儲存在 Google Drive 的照片沖印出來。為了拿到照片，雲端沖印網站必須獲取使用者的授權去取得存在 Google Drive 的照片，那要如何獲取這個使用者授權呢？我們就用這個例子來做說明：
| 名詞 | 解釋 |
|---|---|
| Resource Owner | 資源擁有者，也就是使用者，Google Drive 照片的擁有者 |
| Client | 客戶端（第三方應用），也就是雲端沖印網站 |
| Authorization Server | 授權（認證）伺服器，即 Google 用來處理授權（認證）的伺服器 |
| Resource Server | 資源伺服器，即存放 Google Drive 照片的伺服器。它與授權（認證）伺服器，實體上可以是同一台伺服器，也可以是不同的伺服器 |
| Access Token | 訪問令牌。使用合法的訪問令牌獲取受保護的資源 |
步驟
- 首先，客戶端（也就是雲端沖印網站）向資源擁有者（即使用者）請求授權。
- 資源擁有者授權後，返回授權憑證（如：authorization code）。
- 客戶端通過授權（認證）伺服器進行身份驗證，並提供授權憑證（如：authorization code），請求訪問令牌。
- 授權伺服器對客戶端進行身份驗證，並驗證授權憑證，如果有效，則發出訪問令牌。
- 客戶端向資源伺服器請求受保護的資源，並提供訪問令牌供驗證。
- 資源伺服器驗證訪問令牌，如果正確則返回受保護資源。
授權方式
從上述步驟說明，我們可以了解到，要獲取 access token 必須先得到使用者授權（authorization grant），那麼如何獲取使用者授權呢？OAuth 2.0 定義了四種型別的授權型式如下：
- 授權碼模式（authorization code）
- 簡化模式（implicit）
- 密碼模式（resource owner password credentials）
- 客戶端模式（client credentials）
基於篇幅的關係，以下僅就功能最完整、使用最廣泛、流程最嚴密的授權碼模式做說明。
授權碼模式
由於這是一個基於重定向（redirect）的流程，所以客戶端必須能夠與資源擁有者的使用者代理（通常是 Web 瀏覽器）進行互動，並且能夠從授權（驗證）伺服器接收傳入的請求（透過網頁重定向）。
- 使用者訪問客戶端（即雲端沖印網站），客戶端將使用者導向授權（驗證）伺服器（即 Google 的身份識別服務），通過使用者代理（即瀏覽器）傳送包括它的客戶端識別符號、請求的範圍、本地狀態和一個重定向 URI，授權伺服器在授予（或拒絕）訪問權後將其傳送給使用者代理（即瀏覽器）。
- 授權（驗證）伺服器對資源所有者進行身份驗證（通過瀏覽器），並確定資源所有者是否授予或拒絕客戶端的訪問請求。
- 假如資源所有者（即使用者）同意授權請求，那麼授權（驗證）伺服器將會使用前面提供的或者事先指定的重定向 URI 重定向到客戶端，並附上一個授權碼（code）和一個前面提供的本地狀態（state），如果有的話，則會原值返回。
- 客戶端（即雲端沖印網站）收到授權碼，附上早先的重定向 URI，向授權（驗證）伺服器申請令牌。這一步是在客戶端後臺的伺服器上完成的，對使用者不可見。在發出請求時，授權伺服器對客戶端進行身份驗證。請求引數包含授權程式碼、用於獲得驗證的授權程式碼的重定向 URI、標識客戶端身份的 client id 和 client secret。
- 授權伺服器對客戶端進行身份驗證，驗證授權程式碼，並確保所收到的重定向 URI 與用於在步驟 3 中對客戶端重定向的 URI 相匹配，如果有效，授權伺服器將傳送訪問令牌和重新整理令牌（refresh token）（選用）。
從 OAuth 2.0 的模型概念步驟說明，我們不難看出，OAuth 2.0 的設計本意更偏向於授權而非身份認證。不過如果授權的內容是使用者資訊而非本例為了易於理解所舉例的照片，那麼這個授權的機制也就成了可以運用在 SSO 的身份認證機制。
