Miles' Blog

OAuth2 定義兩種 Client 類型：confidential 與 public 兩種。之前不管 OAuth2 或是 OpenID Connect，在說明流程的時候，都是以 confidential client，搭配較安全的 Authorization Code Grant / Authorization Code Flow 作為範例，但終究還是會面對相較不安全的 public client。

OpenID Connect Core 定義了很完整的身分驗證流程，但一個良好可擴展的協定會是抽象化的，會保留一些細節在未來由其他協定來補充，或是留給實作者定義。

以目前而言，OAuth 2.0 授權框架（下簡稱 OAuth2）定義了一個相較安全的授權流程。但身分驗證並不在 OAuth2 的範疇內，而今天簡介的 OpenID Connect 正是基於 OAuth2 的基礎上，再另外定義了身分驗證的流程。

OAuth 2.0 對於授權流程的規範非常清楚，但它僅僅只定義到 client 拿到 token 而已。

Authorization Code Grant 是相較其他三種授權類型而言，最複雜的一種。但就讓使用者授護的目的而言，這個授權類型相較設計的比較合理也安全。

之前在討論 API 身分驗證時，已有小提一下 OAuth 2.0 授權框架（以下簡稱 OAuth2）的概觀了。

在使用 JWT 時，必須得先了解它的特性，才不會踩到禁區或是誤解 JWT 的目的。

JWK 與 JWA 定義了 JWS 與 JWE 所能使用的演算法，以及金鑰（key）的格式。

JWS 能保護資料的完整性，但資料傳輸過程是明碼傳輸，因此有心人士還是有辦法截取 JWS Payload 裡的內容做其他利用。如果內容也不希望被其他人看到的話，那還有另一個選擇就是 JWE－－RFC 7516 - JSON Web Encryption。

JWS 的全名為 JSON Web Signature，定義在 RFC 7515 裡面，主要定義了資訊的格式以及序列化（serialization）的方法。從名字可以看得出，它有使用到數位簽章技術，或是它也可以使用訊息驗證碼來確保資料的來源以及完整性。