大家都知道OAuth 2.0 有四種不同的grant type，分不同的業(yè)務場景來使用，我在前面的一篇文章也有粗略講過 微服務架構學習筆記之一認證和授權 - 大概怎么去按照不同業(yè)務場景來使用OAuth 2.0的不同grant type, 比如下面這張圖
但是很多時候還是不能很好的理解為什么要這么劃分，關鍵點在哪里？這又回退到我們要清楚的知道OAuth 2.0 四種不同的grant type的區(qū)別是什么。
首先我們先羅列4種的OAuth 2.0的grant type
Authorization Code Flow
Implicit Flow
Resource Owner Password Credential Flow
Client Credential Flow
要回答這四種不同的grant type的區(qū)別是什么，需要考慮以下維度：
- 需不需要用戶輸入用戶名密碼？
- Client Application是第三方應用還是第一方應用？
- 用戶輸入用戶名和密碼的界面是誰來提供的？Authorization Server還是第三方應用？
- Client Application(需要訪問你的資源的應用)能否感知和存儲authorization code和access token?
對于第一個問題，4種grant type中只有client credential flow是不需要用戶輸入用戶名和密碼，這也就不難解釋為什么在只有機器執(zhí)行的場景下，那么就需要采用client credential flow這種OAuth 2.0的方式，只需要約定好client id和client secret就可以去換取access token來進行resource的訪問。這種業(yè)務場景一般發(fā)生在有些服務器需要定時執(zhí)行一些job的情況。
對于第二個問題，Client Application是第三方應用還是第一方應用？一般來講，如果是第一方應用（自己開發(fā)的應用）一般我們都認為要安全一些，因為不會故意的去泄露訪問resource的access token， 所以一般第一方應用我們可以使用簡單的resource owner password credential flow, 這種OAuth 2.0 grant type 節(jié)省了通過code去交換access token這一步驟（實際上就是節(jié)省了一次網(wǎng)絡請求來回），直接通過用戶名，密碼去獲取access token。而第三方應用我們需要采用更加安全的OAuth 2.0 flow, 比如authorization code flow 或者 implicit flow. 至于究竟是選擇authorization code flow 還是 implicit flow, 那么可以參見下面第四個問題的回答。
對于第三個問題， 這個也是出于安全性的考慮，我們可以看到，authorization code flow 和 implicit flow 的用戶輸入credential的界面都是由authorization server提供的H5 page，而resource owner password credential flow則是由client application提供的page (可以是Native App Page, 也可以是H5 Page), 由authorization server提供的H5 page會更加安全一點。
對于第四個問題，Client Application(需要訪問你的資源的應用)能否感知和存儲authorization code和access token? 我們都知道最常用的是authorization code flow，它是最安全的，它需要先通過用戶的身份驗證，然后獲得一個code，再拿這個code去authorization server交換access token和refresh token。而我們都知道access token本身是有時效性的，如果有人很容易的拿到code 或 refresh token，那么就基本上可以隨意隨時的去訪問你的resource了，因為他可以不斷的通過refresh token 去刷新access token。 而為什么第三方的SPA使用的是implicit flow 而第三方的Native App卻使用的是authorization code flow？ 理論上第三方應用都應該使用authorization code flow，但是如果你仔細看下，implicit flow中是沒有code 和 refresh token的，而SPA應用(本質上是web，需要通過瀏覽器的)更加容易去暴露code 和 refresh token， 所以才在第三方的SPA應用中使用了implicit flow，而只給了access token， 一旦過期，則需要重新用戶名密碼驗證。
