User Authorization — OAuth 2.0
基本概念
前面的文章有談到使用者認證(User Authentication)
其實可以延伸出：
- Identification — 識別，表明你的身份。
- Authentication — 證明，證明你的身份。
- Authorization — 授權，當你證明你是誰後，接著就看看你能做些什麼。
例如登入一個網站通常要輸入帳號與密碼，帳號就等同於Identification，而帳號+密碼就等於Authentication。若通過證明後，就可以進到Authorization步驟，授權你做什麼事情。
而 OAuth 2.0 就是專注於使用者授權的標準協定，所謂的協定就是說，大家講好要用什麼方式做事情，舉個最常見的例子，你在某旅遊網站要註冊帳號，該網站有提供使用Google帳戶註冊/登入，於是你按下註冊後就彈出Google的視窗要你登入Google帳戶。
在這裡就是由Google去提供[證明] — 你跟Google證明你是某某。
當你成功證明你是誰之後，Google就會[授權]某旅遊網站，給他一些必要的資訊，例如email 或者avatar。所以當你在要授權之前，提供者都會詢問你是否要提供某些資料給第三方網站，而[授權]這個動作使用的協議就是OAuth 2.0。
例如：https://developers.google.com/accounts/images/OAuth2Consent.png
案例
而拆解這個流程就是：
使用者 -> 網站：我要用G帳號登入你的網站
網站 -> 使用者：好啊，但是你要先跟G說，我才可以跟G拿東西，我先安排你跟G見面。
G -> 使用者：好啊…等等，我要先確認你的身分….嗯嗯嗯，身分確認無誤，這個暗語給你，你把暗語給網站，叫他用暗語跟我換鑰匙(Access token)，我載你回網站那邊。
使用者 -> 網站：我拿到暗語了！給你，你拿去換鑰匙(Access token)吧。
網站 -> G：暗號是"反清復明”對吧，
G -> 網站：沒錯沒錯，鑰匙(Access token)給你。
網站 -> 使用者：我拿到G的鑰匙(Access token)了，讓你登入囉。
角色
講完了基礎概念後，我們可以來了解協定的細節。
OAuth定義了四種角色(Roles)，這裡以我的理解來解釋：
- Resource owner：資源擁有者，擁有資料的人，例如Google、Facebook。
- Resource server：資源擁有者住的地方，Client才知道要去哪裡要資料。
- Client：客戶端，也就是網站/應用程式、要求資源的人。
- Authorization server：對Client發行Token的地方，Resource server與Authorization server可以是同一台server，也可以不同。
授權類型
上圖就是OAuth協定的流程，
Authorization Grant(授權許可)：Resource owner發放給client的一個證書，讓client可以跟Authorization server換取token，總共分為四種類型：
- Authorization Code(授權碼)：簡單的說就是client透過Resource owner轉向Authorization server去要許可，再將授權碼透過Resource owner傳回client。應用場景：Server-side Applications
- Implicit：由Authorization server直接發送token給client，不另外發送Authorization Code作為交換，好處是改善了回應次數、增進效率。但是增加了風險(對比Authorization Code而言)，可以利用redirection URI來驗證client是否正確。應用場景：Mobile Apps or Web Applications
- Resource Owner Password Credentials：直接使用username & password當作Authorization Grant(授權許可)去拿到token，這個類型只有在非常信任client端的情況下才建議使用。應用場景：內部系統
- Client Credentials：由client本身同為Resource owner，直接跟Authorization server要求token。應用場景：存取API或公開資源
發行與換發證明
Access Token：允許你存取資料的一組字串，如先前所說，token是由Authorization server發行，token應該設計成能夠表示特定的存取權限與存取時間。
Refresh Token：如果現有的Access Token失效或者過期，就得重新發送token。只有在Authorization server發送Access Token有一併發送Refresh Token，才可以利用Refresh Token重新換發access token。Refresh Token是存在client，resource owner不會也不需要知道refresh token。
下圖就是一個換發過期access token的流程：
利用這樣的一組協定，讓資源提供者在使用者的同意之下分享使用者的個人資料給第三方網站/應用時，不必提供使用者的帳號密碼，而是用一組token，並且資源提供者可以控管token，例如使token失效，這樣第三方應用就得重新要求存取權限。
