今天來看看 identity management 的簡史

各家自掃門前雪時代

在軟體服務發展的早期，各家系統各自管理使用者的帳號密碼。從系統的角度來看，非常方便管理，也不需要跟其他的系統溝通。

但是從使用者的角度來看，每使用一個新的軟體服務，就需要建立新的使用者名稱和密碼，到最後就有數不完的帳號密碼需要記，產生許多麻煩。即便是同一家公司所提供的不同服務，都需要不同的帳號密碼去驗證。

集中管理時代的 user repository

之後開始有人想到，不如我們就集中化管理使用者的帳號密碼吧！於是在公司裡面就出現了 user repository 的服務，集中管理與驗證使用者，因此對一位使用者來說，他只要使用一套帳號密碼，就可以訪問同一家公司當中的不同服務。

然而這時候又有另外一個問題，那麼就是當使用者輸入密碼登入服務 A 之後，如果想要前往同一間公司的服務 B，雖然是使用同一套帳號密碼，但還是必須再手動輸入一次，使用者依舊覺得麻煩。

只要登入一次就行的 SSO

回應上面提到的問題 Single Sign-On (SSO) 就此誕生。SSO 的實作方式有許多種，簡單來說是在 user repository 服務之外，加入一層 SSO 服務，負責統一管理使用者的 session。

當使用者已經登入服務 A，準備要登入服務 B 的時候，這時瀏覽器會先將使用者導回到 SSO 服務，讓 SSO 服務檢查是否該使用者已經登入過其他服務。如果已經登入，那麼就直接讓使用者進入服務 B；若還沒登入，那麼就會導回到使用者驗證（登入）畫面。

這對使用者來說，使用體驗已經提升不少，但僅限於同一個網域下的服務才能實現 SSO。如果今天是同一間公司的不同服務在不同網域，會 cookie 的限制而無法實現簡單的 SSO。

SAML

2005 年 SAML (Security Assertion Markup Language) 推出，其目的在於規範「在不同系統之間交換 authentication 和 authorization」的資訊，而其中最重要的使用場景，就是跨域的 SSO。

然而 SAML 或其後出現的 SAML 2.0 能夠解決 server-side rendering 網站的 SSO 問題，卻無法完全解決後來出現的 client-side rednering 網站以及手機 native app 的 SSO 問題。

OAuth

隨著社群網站的興起，越來越多的使用場景是，使用者需要授權一個系統來存取另外一個系統的資訊，也就是使用者需要授權特定的 API request。因此一個新的 authorization framework OAuth 在 2009 推出，來處理這樣的問題。OAuth 2.0 規範 在 2013 年推出，但沒有向下相容 OAuth。

雖然 OAuth 2.0 解決了資源存取的授權問題，但並沒有提供標準化的 authentication 的方法，也因此需要額外的規範來輔助完整的 authentication 和 authorization。

OpenID

OpenID 常常與 OAuth 2.0 一起出現，但其實最早版本的 OpenID 比 OAuth 還要早誕生，目的是希望建構一個標準的、去中心化的使用者驗證規範。

第三代的 OpenID Connect 和 OAuth 2.0 ，成為目前常見的 authentication 和 authorization 問題的解決規範。

接下來幾天，會深入探索 OAuth 2.0、OpenID Connect、SAML 2.0 的細節