最後一天，來討論一個實際應用：使用者模擬（user impersonation）功能。

第一天在定義範圍時，提到只討論 Web 上的身分驗證。而在鐵人賽即將結束的這一刻，來聊聊 Native App 上該怎麼透過 Web 做身分驗證吧！

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）的格式。