Oauth2協(xié)議

reference:

https://colobu.com/2017/04/28/oauth2-rfc6749/
oauth2官網(wǎng)
oauth1.0今阳、oauth1.0a、oauth2區(qū)別
access_token足夠安全嗎

1. 基本概念

Oauth2

一個標準的授權(quán)協(xié)議,用來解決如何安全的在客戶端和服務(wù)器之間數(shù)據(jù)傳遞。oauth2面向一個通用模型，支持不通場景下的安全授權(quán)，能將暴露在互聯(lián)網(wǎng)區(qū)的資源或服務(wù)安全可靠的提供出去。

1. 解決問題:

資源所有者為了給第三方應(yīng)用提供受限資源的訪問唐瀑，需要與第三方共享它的憑據(jù)群凶。這造成一些問題和局限：

1. 需要第三方應(yīng)用存儲資源所有者的憑據(jù)，以供將來使用哄辣，通常是明文密碼请梢。
2. 需要服務(wù)器支持密碼身份認證，盡管密碼認證天生就有安全缺陷力穗。
3. 第三方應(yīng)用獲得的資源所有者的受保護資源的訪問權(quán)限過于寬泛毅弧，從而導致資源所有者失去對資源使用時限或使用范圍的控制。
4. 資源所有者不能僅撤銷某個第三方的訪問權(quán)限而不影響其它当窗，并且够坐，資源所有者只有通過改變第三方的密碼，才能單獨撤銷這第三方的訪問權(quán)限崖面。
5. 與任何第三方應(yīng)用的讓步導致對終端用戶的密碼及該密碼所保護的所有數(shù)據(jù)的讓步元咙。

上述更具體點的描述可以將資源所有者替換成微信，受限資源可以替換成微信賬號信息巫员。

2. 概念抽象

OAuth通過引入授權(quán)層以及分離客戶端角色和資源所有者角色來解決這些問題庶香。
在OAuth中，客戶端在請求受資源所有者控制并托管在資源服務(wù)器上的資源的訪問權(quán)限時简识，將被頒發(fā)一組不同于資源所有者所擁有憑據(jù)的憑據(jù)赶掖。

Oauth是一種客戶端授權(quán)：客戶端獲得一個訪問令牌（一個代表特定作用域、生命期以及其他訪問屬性的字符串）七扰，用以代替使用資源所有者的憑據(jù)來訪問受保護資源奢赂。
訪問令牌由授權(quán)服務(wù)器在資源所有者認可的情況下頒發(fā)給第三方客戶端【弊撸客戶端使用訪問令牌訪問托管在資源服務(wù)器的受保護資源呈驶。

2. 定義

ResourceOwner

資源所有者，能夠許可受保護資源訪問權(quán)限的實體疫鹊。比如個人

ResourceServer

存放資源的服務(wù)器袖瞻，能夠接收和響應(yīng)使用令牌對資源的請求司致。

Client

該客戶端指第三方應(yīng)用程序，具體請求資源服務(wù)器的客戶端聋迎。而不是指瀏覽器這類客戶端脂矫。

AuthorizationServer

授權(quán)服務(wù)器，主要用于驗證資源所有者并授權(quán)分配令牌霉晕。授權(quán)>認證庭再，基本上我們的授權(quán)都會有個認證的動作。在具體部署上牺堰、可以按實際項目也可以將資源服務(wù)器和授權(quán)服務(wù)器作為同一個應(yīng)用來部署拄轻。

UserAgent

代理客戶端，比如瀏覽器伟葫，手機App.

Authorization Code

授權(quán)碼恨搓。授權(quán)標識，因為它會在瀏覽器上(非服務(wù)端)傳輸筏养，而非服務(wù)端傳遞的數(shù)據(jù)我們都認定是不安全的斧抱，即使是https。所以它是短期有效的一次性數(shù)據(jù)渐溶。

Oauth2 openId

oauth2是授權(quán)協(xié)議辉浦，但我們可以看到平臺都是基于oauth2實現(xiàn)的單點登錄。這個其實就是oauth2-openId茎辐。openId是認證協(xié)議宪郊，而我們知道`授權(quán)>認證`。單點登錄解決的就是多應(yīng)用認證問題拖陆，oauth2-openId就是將用戶信息作為資源服務(wù)提供出去废膘。如果當前用戶信息都能傳遞出去了，那么肯定能確定當前用戶是誰了慕蔚。

3. 流程

oauth2.png

大致流程都是client申請授權(quán)丐黄、resourceServer分配token.
而為了解決多種授權(quán)場景,oauth2有4種授權(quán)模式

授權(quán)碼模式-Authorization Code

grantCode.png

支持場景：有服務(wù)端的應(yīng)用。
主要就是使用authorization code 換取token孔飒。code安全性問題灌闺，所以才有后面的服務(wù)端交互token傳遞。

隱式許可模式-Implicit Grant

implicit.png

支持場景：純前端應(yīng)用坏瞄，不含服務(wù)端桂对。
授權(quán)回調(diào)地址后面直接拼上#access_token=xxx.需注意的是對該類應(yīng)用的授權(quán)需要保證數(shù)據(jù)安全性問題。該access_token為弱安全性的token鸠匀。

資源所有者密碼校驗-Resource Owner Password Credentials

resourceowner_pwd.png

支持場景：涉及用戶名和密碼蕉斜，所以此授權(quán)類型僅適用于可信賴的應(yīng)用。比如自建App

客戶端憑據(jù)-Client Credentials

client_credentials.png

支持場景：第三方應(yīng)用授權(quán)，交互不涉及ResourceOwner.僅適用于獲取與用戶無關(guān)的公共信息宅此。比如管理Api授權(quán)

3. 安全性

3.1 信息泄漏

主要包括 Authorization Code 泄漏机错、Access Token 泄漏、AppSecret 泄漏父腕。

Authorization Code 泄漏

解決方案：code一次性使用弱匪、縮小有效期
Access Token 泄漏，泄漏分為鏈路傳輸泄漏和應(yīng)用終端泄漏璧亮。

解決方案：
1. 鏈路傳輸上使用https
2. 適量縮小token有效期
3. 服務(wù)使用簽名,簽名包含appSecret.
4. 重要服務(wù)進行二次校驗
AppSecret泄漏

這種場景就基本無法處理萧诫，你連appSecret都能泄漏出去了，還能保障什么安全枝嘶。
雖然可以考慮對第三方應(yīng)用配置白名單帘饶，但是會增加管理復雜度，不符合oauth2的目標群扶。

3.2 CSRF

主要包括授權(quán)劫持和綁定劫持及刻。授權(quán)劫持是指用戶在目標網(wǎng)站處于登錄狀態(tài)的情況下，攻擊者通過偽造授權(quán)鏈接來誘騙用戶點擊穷当，用戶訪問攻擊者的鏈接后，攻擊者就會劫持用戶授權(quán)淹禾。綁定授權(quán)同樣是在用戶處于登錄狀態(tài)的情況下馁菜，攻擊者通過用戶授權(quán)登錄目標網(wǎng)站并阻斷用戶授權(quán)流程，進而誘騙用戶點擊铃岔，用戶在訪問攻擊者的鏈接后汪疮，攻擊者就可以劫持用戶授權(quán)。

解決方案：

state校驗.在authorization_code模式中,申請授權(quán)鏈接帶上state,授權(quán)成功分配code的時候會將state帶回去毁习。授權(quán)應(yīng)用再將state與會話中的state進行對比智嚷。

3.3 URL 回調(diào)污染

主要是指由于 redirect_uri 回調(diào)地址填寫不嚴格或者授權(quán)服務(wù)器不驗證或者驗證不嚴格而導致的 code 或者 access_token 泄露。

解決方案：

在應(yīng)用管理中纺且，配置應(yīng)用的授權(quán)回調(diào)域盏道，并在授權(quán)過程中校驗授權(quán)回調(diào)域。

3.4 權(quán)限認證

主要是指 OAuth 高級授權(quán)接口的越權(quán)訪問载碌，比如 GitHub 的 scope 漏洞猜嘱，導致可以訪問私有代碼區(qū)。

解決方案：

在服務(wù)上進行token權(quán)限級別劃分

3.5 不區(qū)分調(diào)用方式

主要是指在 Authorization Code 和 Implicit 兩個調(diào)用方式嫁艇，它們的區(qū)別僅僅是一個參數(shù)朗伶，黑客可以利用這個參數(shù)來繞過 AppSecret 認證。

解決方案：

區(qū)分Authorization Code和Implicit 兩個調(diào)用方式生成的token,兩則可調(diào)用的服務(wù)不同步咪。對于Implicit,我們只能保證一些基本的服務(wù)论皆，比如獲取用戶id，像其他更具體的資源數(shù)據(jù)，我們需要保證數(shù)據(jù)安全性点晴，比如數(shù)據(jù)脫敏感凤。