即使有許多教科書以及第三方套件可以參考，但真的要從頭規劃與設計一個安全的帳號密碼驗證功能，並不是件容易的事。因此有另一個解決方案即為，透過安全可靠的第三方身分驗證提供者（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 身分驗證，是服務與服務，或服務、第三方服務、使用者之間的三角關係
• 第三方驗證已很明確是屬於服務、第三方驗證中心、使用者的三角關係

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

參考資料

• SAML
• OpenID Connect
• BCP 212

註：BCP 全名為 Best Current Practice