前言
OAuth（開放授權(quán)）是一個開放標(biāo)準(zhǔn)戚篙，允許用戶讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲的私密的資源（如照片坎穿，視頻河绽，聯(lián)系人列表），而無需將用戶名和密碼提供給第三方應(yīng)用敢朱。
OAuth 2.0是OAuth協(xié)議的下一版本剪菱，但不向下兼容OAuth 1.0。OAuth 2.0關(guān)注客戶端開發(fā)者的簡易性拴签，同時為Web應(yīng)用孝常，桌面應(yīng)用和手機(jī)，和起居室設(shè)備提供專門的認(rèn)證流程蚓哩。
Oauth2.0定義的 5種角色
- 客戶端（Client）
客戶端是OAuth服務(wù)的接入方构灸，其目的是請求用戶存儲在資源服務(wù)器上的受保護(hù)資源，客戶端可以是移動應(yīng)用岸梨，網(wǎng)頁應(yīng)用等等 - 用戶代理（User Agent)
用戶代理是用戶參與互聯(lián)網(wǎng)的工具喜颁，一般可以理解為瀏覽器 - 資源所有者（Resource Owner)
受保護(hù)資源所屬的實體，比如資源的持有人曹阔，用戶既資源所有者 - 授權(quán)服務(wù)器（Authorization Server)
授權(quán)服務(wù)器的主要職責(zé)是驗證所有者的身份半开，并依據(jù)資源所有者的許可對第三方應(yīng)用下發(fā)令牌 - 資源服務(wù)器（Resource Server）
托管資源的服務(wù)器，能夠接受和相應(yīng)持有令牌的資源訪問請求次兆，可以與授權(quán)服務(wù)器是同一臺服務(wù)器。
基本概念
訪問令牌(access token)
訪問令牌是在用戶授權(quán)許可下锹锰，授權(quán)服務(wù)器下發(fā)給客戶端的一個授權(quán)憑證芥炭，該令牌所要表達(dá)的意思是“用戶授予該APP在多少時間范圍內(nèi)允許訪問哪些與自己相關(guān)的服務(wù)”，所以訪問令牌主要在 時間范圍 和 權(quán)限范圍 兩個維度進(jìn)行控制恃慧，此外訪問令牌對于客戶端來說是非透明的园蝠，外在表現(xiàn)就是一個字符串，客戶端無法知曉字符串背后所隱藏的用戶信息痢士，因此不用擔(dān)心用戶的登錄憑證會因此而泄露彪薛。
刷新令牌(refresh token)
刷新令牌的作用在于更新訪問令牌，訪問令牌的有效期一般較短怠蹂，這樣可以保證在發(fā)生訪問令牌泄露時善延，不至于造成太壞的影響，但是訪問令牌有效期設(shè)置太短存在的副作用就是用戶需要頻繁授權(quán)城侧，雖然可以通過一定的機(jī)制進(jìn)行靜默授權(quán)易遣，但是頻繁的調(diào)用授權(quán)接口，之于授權(quán)服務(wù)器也是一種壓力嫌佑，這種情況下就可以在下發(fā)訪問令牌的同時下發(fā)一個刷新令牌豆茫，刷新令牌的有效期明顯長于訪問令牌侨歉，這樣在訪問令牌失效時，可以利用刷新令牌去授權(quán)服務(wù)器換取新的訪問令牌揩魂，不過協(xié)議對于刷新令牌沒有強(qiáng)制規(guī)定幽邓，是否需要該令牌是客戶端可以自行選擇。
回調(diào)地址(redirect uri)
OAuth2.0 是一類基于回調(diào)的授權(quán)協(xié)議火脉，在授權(quán)碼模式中牵舵，整個授權(quán)需要分為兩步進(jìn)行，第一步下發(fā)授權(quán)碼忘分，第二步根據(jù)第一步拿到的授權(quán)碼請求授權(quán)服務(wù)器下發(fā)訪問令牌棋枕。OAuth 在第一步下發(fā)授權(quán)碼時，是將授權(quán)碼以參數(shù)的形式添加到回調(diào)地址后面妒峦，并以 302 跳轉(zhuǎn)的形式進(jìn)行下發(fā)重斑，這樣簡化了客戶端的操作，不需要再主動去觸發(fā)一次請求肯骇，即可進(jìn)入下一步流程窥浪。
回調(diào)請求的設(shè)計卻存在一個很大的安全隱患，壞人如果在客戶端請求過程中修改了對應(yīng)的回調(diào)地址笛丙，并指向自己的服務(wù)器漾脂，那么壞人可以利用這種機(jī)制去拿到客戶端的授權(quán)碼，繼而走后面的流程胚鸯，最終拿到訪問令牌骨稿，另外壞人可以利用該機(jī)制引導(dǎo)用戶到一個惡意站點，繼而對用戶發(fā)起攻擊姜钳。以上兩點都是該機(jī)制對于用戶所造成的安全威脅坦冠，對于授權(quán)服務(wù)器而言，也存在一定的危害哥桥，壞人可以利用該機(jī)制讓授權(quán)服務(wù)器變成“請求發(fā)送器”辙浑，以授權(quán)服務(wù)器為代理請求目標(biāo)地址，這樣在消耗授權(quán)服務(wù)器性能的同時拟糕，也對目標(biāo)地址服務(wù)器產(chǎn)生 DDOS 攻擊判呕。
為了避免上述安全隱患，OAuth 協(xié)議強(qiáng)制要求客戶端在注冊時填寫自己的回調(diào)地址送滞，這個回調(diào)地址的目的是為了讓回調(diào)請求能夠到達(dá)客戶端自己的服務(wù)器侠草，從而可以走獲取訪問令牌的流程±缧幔客戶端可以同時配置多個回調(diào)地址梦抢，并在請求授權(quán)時攜帶一個地址，服務(wù)器會驗證客戶端傳遞上來的回調(diào)地址是否與之前注冊的回調(diào)地址相同愧哟，或者前者是后者集合的一個元素奥吩，只有在滿足這一條件下才允許下發(fā)授權(quán)碼哼蛆，同時協(xié)議還要求兩步請求客戶端攜帶的回調(diào)地址必須一致，通過這些措施來保證回調(diào)過程能夠正常達(dá)到客戶端自己的服務(wù)器霞赫，并繼續(xù)后面拿授權(quán)碼換取訪問令牌的流程
權(quán)限范圍 (scope)
訪問令牌自帶過期時間腮介，可以在時間維度上對授權(quán)進(jìn)行控制，而在范圍維度上端衰，OAuth 引入了一個 scope 的概念叠洗。scope 可以看做是一個對象，包含一個權(quán)限的 ID旅东，名稱灭抑，以及描述信息等，比如“獲取您的基本資料（頭像抵代、昵稱）”腾节。應(yīng)該在接入賬號服務(wù)時必須向第三方登錄服務(wù)提供方申請響應(yīng)的 scope，并在請求授權(quán)時指明該參數(shù)（否則表明獲取該應(yīng)用所允許的所有權(quán)限）荤牍，這些權(quán)限在用戶確認(rèn)授權(quán)時案腺，必須毫無保留的展示給用戶，以讓用戶知道該APP需要獲取用戶的哪些數(shù)據(jù)或服務(wù)康吵。
基本授權(quán)流程
- Client請求Resource Owner的授權(quán)劈榨，請求一般包含：要訪問的資源路徑，操作類型晦嵌，Client的身份等信息同辣。
- Resource Owner批準(zhǔn)授權(quán)，并將“授權(quán)證據(jù)”發(fā)送給Client惭载。
- Client向Authorization Server請求“訪問令牌”旱函。此時，Client需向AS提供RO的授權(quán)證據(jù)以及Client自己身份的憑證棕兼。
- AS通過驗證后陡舅，向Client返回“訪問令牌”抵乓，
- Client攜帶“訪問令牌”訪問RS上的資源伴挚。
- RS驗證令牌的有效性，比如是否偽造灾炭，越權(quán)等茎芋。
授權(quán)碼模式（Authorization Code Grant）
大部分 APP 的 OAuth 授權(quán)都可以采取授權(quán)碼模式，下圖為授權(quán)碼各個角色之間的交互時序（這里讓用戶直接參與其中蜈出，省略了用戶代理）
- 客戶端攜帶 client_id, scope, redirect_uri, state 等信息引導(dǎo)用戶請求授權(quán)服務(wù)器的授權(quán)端點下發(fā) code
- 授權(quán)服務(wù)器驗證客戶端身份田弥，驗證通過則詢問用戶是否同意授權(quán)（此時會跳轉(zhuǎn)到用戶能夠直觀看到的授權(quán)頁面，等待用戶點擊確認(rèn)授權(quán)）
- 假設(shè)用戶同意授權(quán)铡原，此時授權(quán)服務(wù)器會將 code 和 state（如果客戶端傳遞了該參數(shù)）拼接在 redirect_uri 后面偷厦，以302形式下發(fā) code
- 客戶端攜帶 code, redirect_uri, 以及 client_secret 請求授權(quán)服務(wù)器的令牌端點下發(fā) access_token （這一步實際上中間經(jīng)過了客戶端的服務(wù)器商叹，除了 code，其它參數(shù)都是在應(yīng)用服務(wù)器端添加只泼，下文會細(xì)講）
- 授權(quán)服務(wù)器驗證客戶端身份剖笙，同時驗證 code，以及 redirect_uri 是否與請求 code 時相同请唱，驗證通過后下發(fā) access_token弥咪，并選擇性下發(fā) refresh_token
內(nèi)部應(yīng)用可以拿著第三方應(yīng)用的 client_id 等信息代替第三方應(yīng)用去請求獲取 code，因為自己持有用戶的登錄態(tài)十绑，所以過程中無需用戶再次輸入用戶名和密碼聚至，拿到 code 之后將其交給第三方應(yīng)用，第三方應(yīng)用利用 code 和自己的 client_secret 信息去請求授權(quán)服務(wù)器下發(fā) token本橙，整個流程內(nèi)部應(yīng)用不需要交出自己持有的用戶登錄態(tài)扳躬，第三方應(yīng)用也無需交出自己的 client_secret 信息，最終卻能夠?qū)崿F(xiàn)在保護(hù)用戶登錄憑證的前提下無需再次登錄即可完成整個授權(quán)流程
