第三方身分驗證

即使有許多教科書以及第三方套件可以參考,但真的要從頭規劃與設計一個安全的帳號密碼驗證功能,並不是件容易的事。因此有另一個解決方案即為,透過安全可靠的第三方身分驗證提供者(provider)來幫忙做驗證,在開發產品只要專心實現商模即可。

除此之外,身分驗證中心是中央集權,因此驗證方法或使用者憑證(如密碼)都會一致,這對容易忘記密碼的金魚腦使用者,會是個值得高興的結果。而對身分驗證中心而言,它只要專心致力於維護帳號系統的安全與穩定即可,完全符合單一職責原則,這大大了提高各服務的可維護性。

如果有達到理想的單一職責原則,則在設計上,服務與身分驗證中心應該可以是兩個完全沒有關係的單位,只依賴協定的要求即可互相信任。因此,了解有哪些協定以及內容,對串接第三方身分驗證是有必要的。

相關的協定

目前聽過的第三方身分驗證協定有 SAML 以及 OpenID Connect 兩個。

SAML 是一個 2001 年所發布的協定,而最後版本 SAML 2.0 是在 2005 年發布,與 HTTP 一樣,是一個歷史長久且穩定的協定。這是優勢,同時也是劣勢。歷史長久意味著實作與使用者多,也歷經時間的考驗,證明它的穩定與安全性。但,2005 年並沒有行動裝置,也不可能有 App,因此協定設計上欠缺了以 App 為情境的考量。

OpenID Connect 是 2014 年發布,它基於 OAuth 2.0 的流程,以及使用 JWT 做為身分憑證的格式。同時它更是原生 App 身分驗證的目前最佳實踐。未來將會直接介紹此協定相關內容。

替代方案

SAML 與 OpenID Connect 的目的都包含了身分驗證。除此之外,還有一個替代做法即為「OAuth 登入」,上面剛好也提到「OpenID Connect 基於 OAuth 2.0 的流程」,那麼它們兩個之間的差異主要在於,OAuth 2.0 只討論如何授權,不討論身分驗證;而 OpenID Connect 則是在授權框架上,加上了身分驗證流程。

所以「OAuth 登入」究竟是?這是因為在大部分的場景裡,OAuth 提供者必須要先知道「我是誰」--也就是身分驗證,才能知道是誰的資源要授權給第三方應用程式。因此在授權成功(即拿到 access token)的同時,其實 OAuth 提供者也同時完成了身分驗證,這就是所謂的「OAuth 登入」。

小結

這三天所聊的身分驗證,包括帳號密碼驗證API 身分驗證,還有今天的第三方驗證,在概念上的差異為:

  • 帳號密碼驗證,是使用者與服務之間一對一的關係
  • API 身分驗證,是服務與服務,或服務、第三方服務、使用者之間的三角關係
  • 第三方驗證已很明確是屬於服務、第三方驗證中心、使用者的三角關係

會需要理解這些差異的理由是,在身分驗證的過程裡,不同的角色有不同的職責,「我在哪」、「做什麼事」以及「我要去哪裡」是需要明確地定義與限制,才有辦法安全地驗證使用者身分。

參考資料

註:BCP 全名為 Best Current Practice