昨天介紹了 OAuth 出現的背景以及早期使用的 OAuth 1.0 的授權角色以及流程，不過如今大部分的第三方應用程式主要都是透過 OAuth 2.0，所以今天會來介紹一下 OAuth 2.0 以及他與 OAuth 1.0 有什麼差異，以及為什麼要選擇使用 OAuth 2.0 ，那就開始今天的內容吧！
在昨天的流程介紹中可以知道，在授權完成後 client 就可以透過 token 憑證去向 server 請求 resource owner 的資料。可是，對於 resource owner 來說，他可能只想要允許 client 存取今年上傳的圖片，其他的他並不想要被 client 取得。那這個沒有定義明確範圍（scope）的 token，就會造成 client 擁有過大的權限，而且 resource owner 還沒有辦法對此進行限制。
OAuth 1.0 主要側重於透過瀏覽器進行互動，對於移動式應用並不是很適用，都必須要求用戶打開瀏覽器進行操作，效率很低。
在 OAuth 1.0 中用戶端發出請求都需要透過 HMAC-SHA1 演算法進行簽名，流程較複雜，而 OAuth 2.0 則透過 HTTPS 進行加密的傳送，所以不需要再經過複雜的簽名就可以進行傳送。
OAuth 1.0 中的 token 憑證效期都很長，而 OAuth 2.0 引進了 refresh token 以及 access token，可以發送效期較短的 access token ，效期過了之後 client 可以 透過發送 refresh token 去請求新的 access token，無需 resource owner 重新進行授權。
先來看一下 OAuth 2.0 的角色定義吧！在RFC 6749中，定義了以下四個角色：
上圖來自RFC 6749，簡單了介紹OAuth2.0的流程
其實和昨天的流程沒有太大的差異，差別在於：
token 是由 authorization server 發送，分為 refresh token 以及 access token 兩種，client 會透過 access token 向 resource server 去請求資料，而當 access token 效期過了之後，client 就可以使用 refresh token 向 authorization server 請求新的 access token，不需要 resource owner 再進行一次授權。
當 client 首次對 authorization server 發出請求時，除了會傳送 redirect URI 之外，也會傳送一個 Scope 的參數，內容紀錄了他需要取得的授權範圍是什麼。
在 OAuth 1.0 流程中，有一個部分其實我在看的時候很疑惑，為什麼在 google drive 完成授權並重定向回到 facebook 的時候，不直接將 token 憑證一起回傳就好，而是透過oauth_verifier回傳一段授權碼，最後再由 facebook 將臨時憑證以及授權碼向 google drive 交換 token憑證呢？同樣在 OAuth 2.0的授權碼模式也是，client 會先收到授權碼，再據此向 authorization server 交換 token，那為什麼要多這個步驟呢？
在 OAuth 的流程中，有一個概念：front channel 以及 back channel，前者指的像是瀏覽器，安全性不會到很高，而後者指的則是伺服器間的互動，被認為是高度安全性的。
直到交換 token 前面的步驟都是屬於 front channel ，如果透過瀏覽器去傳送 token 憑證，把這個 token 存放在 HTML 或是 javascript 中的話，是很有可能透過惡意工具或是源代碼被第三方得知的。因此在
OAuth 流程中只會透過瀏覽器（front channel）進行傳送授權碼，最後才會透過 client 去向 authorization server（back channel）交換 token 憑證，以免遭受攔截，被惡意第三人拿去使用。
今天簡單介紹了從 OAuth 1.0 到 OAuth 2.0 的一些差異，以及我遇到的一點小困惑，而 OAuth 主要在意的重點只在於『可以做什麼』，至於要知道『你是誰』的話，就只能透過 OpenID Connect 了，明天再來介紹這個部分的概念，那就明天見啦～
RFC 6749
OAuth 2.0 and OpenID Connect (in plain English)
iThome鐵人賽
看影片追技術