概述
客戶端必須得到用戶的授權(quán)（authorization grant），才能獲得令牌（access token）忙上。oAuth 2.0 定義了四種授權(quán)方式调俘。
- implicit：簡化模式辜窑，不推薦使用
- authorization code：授權(quán)碼模式
- resource owner password credentials：密碼模式
- client credentials：客戶端模式
簡化模式
簡化模式適用于純靜態(tài)頁面應(yīng)用奖恰。所謂純靜態(tài)頁面應(yīng)用吊趾，也就是應(yīng)用沒有在服務(wù)器上執(zhí)行代碼的權(quán)限（通常是把代碼托管在別人的服務(wù)器上），只有前端 JS 代碼的控制權(quán)瑟啃。
這種場景下论泛，應(yīng)用是沒有持久化存儲的能力的。因此蛹屿，按照 oAuth2.0 的規(guī)定屁奏，這種應(yīng)用是拿不到 Refresh Token 的。其整個(gè)授權(quán)流程如下：
該模式下蜡峰，access_token容易泄露且不可刷新
授權(quán)碼模式
授權(quán)碼模式適用于有自己的服務(wù)器的應(yīng)用了袁，它是一個(gè)一次性的臨時(shí)憑證，用來換取 access_token 和refresh_token湿颅。認(rèn)證服務(wù)器提供了一個(gè)類似這樣的接口：
https://www.xxm.com/exchange?code=&client_id=&client_secret=
<p>需要傳入 code载绿、client_id 以及 client_secret。驗(yàn)證通過后油航，返回 access_token 和 refresh_token崭庸。一旦換取成功，code 立即作廢谊囚，不能再使用第二次怕享。流程圖如下：</p>
這個(gè) code 的作用是保護(hù) token 的安全性。簡單模式下镰踏，token 是不安全的函筋。這是因?yàn)樵诘?4 步當(dāng)中直接把 token 返回給應(yīng)用。而這一步容易被攔截奠伪、竊聽跌帐。引入了 code 之后，即使攻擊者能夠竊取到 code绊率，但是由于他無法獲得應(yīng)用保存在服務(wù)器的 client_secret谨敛，因此也無法通過 code 換取 token。而第 5 步滤否，為什么不容易被攔截脸狸、竊聽呢？這是因?yàn)槊臧常紫却都祝@是一個(gè)從服務(wù)器到服務(wù)器的訪問，黑客比較難捕捉到欲芹；其次蜜葱，這個(gè)請求通常要求是 https 的實(shí)現(xiàn)。即使能竊聽到數(shù)據(jù)包也無法解析出內(nèi)容耀石。
有了這個(gè) code牵囤，token 的安全性大大提高。因此滞伟，oAuth2.0 鼓勵使用這種方式進(jìn)行授權(quán)揭鳞，而簡單模式則是在不得已情況下才會使用。
密碼模式
密碼模式中梆奈，用戶向客戶端提供自己的用戶名和密碼野崇。客戶端使用這些信息亩钟，向 "服務(wù)商提供商" 索要授權(quán)乓梨。在這種模式中鳖轰，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼扶镀。這通常用在用戶對客戶端高度信任的情況下蕴侣，比如客戶端是操作系統(tǒng)的一部分。
一個(gè)典型的例子是同一個(gè)企業(yè)內(nèi)部的不同產(chǎn)品要使用本企業(yè)的 oAuth2.0 體系臭觉。在有些情況下昆雀，產(chǎn)品希望能夠定制化授權(quán)頁面。由于是同個(gè)企業(yè)蝠筑，不需要向用戶展示“xxx將獲取以下權(quán)限”等字樣并詢問用戶的授權(quán)意向狞膘，而只需進(jìn)行用戶的身份認(rèn)證即可。這個(gè)時(shí)候什乙，由具體的產(chǎn)品團(tuán)隊(duì)開發(fā)定制化的授權(quán)界面挽封，接收用戶輸入賬號密碼，并直接傳遞給鑒權(quán)服務(wù)器進(jìn)行授權(quán)即可臣镣。
有一點(diǎn)需要特別注意的是场仲，在第 2 步中，認(rèn)證服務(wù)器需要對客戶端的身份進(jìn)行驗(yàn)證退疫，確保是受信任的客戶端渠缕。
客戶端模式
如果信任關(guān)系再進(jìn)一步，或者調(diào)用者是一個(gè)后端的模塊褒繁，沒有用戶界面的時(shí)候亦鳞，可以使用客戶端模式。鑒權(quán)服務(wù)器直接對客戶端進(jìn)行身份驗(yàn)證棒坏，驗(yàn)證通過后燕差，返回 token。
