一口氣說出 OAuth2.0 的四種授權(quán)方式
本文轉(zhuǎn)載自微信公眾號「程序員內(nèi)點事 」,作者程序員內(nèi)點事。轉(zhuǎn)載本文請聯(lián)系程序員內(nèi)點事公眾號。
上周我的自研開源項目開始破土動工了,《開源項目邁出第一步,10 選 1?頁面模板成了第一個絆腳石 》 ,密謀很久才付諸行動,做這個的初衷就是不想讓自己太安穩(wěn),技術這條路不進步就等于后退,必須要逼著自己學習。
項目偏向于技術實踐,因此不會做太多的業(yè)務堆砌,業(yè)務代碼還是在公司學習比較好。現(xiàn)在正在做技術的選型與儲備,像比較主流的,項目前后端分離、微服務、Springboot、Springcloud 等都會應用到項目中,其實很多技術我也不會,也是在反復的查閱資料求證,探索的過程技術提升真的要比工作中快很多,畢竟主動與被動學習是有本質(zhì)區(qū)別的。
這幾天打算先把項目的前后端分離架構(gòu)搭建完成,既然是前后端分離項目就免不了做鑒權(quán), 所以 oauth2.0 是一個我們不得不了解的知識點。
一、OAuth2.0 為何物
OAuth 簡單理解就是一種授權(quán)機制,它是在客戶端和資源所有者之間的授權(quán)層,用來分離兩種不同的角色。在資源所有者同意并向客戶端頒發(fā)令牌后,客戶端攜帶令牌可以訪問資源所有者的資源。
OAuth2.0 是OAuth 協(xié)議的一個版本,有2.0版本那就有1.0版本,有意思的是OAuth2.0 卻不向下兼容OAuth1.0 ,相當于廢棄了1.0版本。
舉個小栗子解釋一下什么是 OAuth 授權(quán)?
在家肝文章餓了定了一個外賣,外賣小哥30秒火速到達了我家樓下,奈何有門禁進不來,可以輸入密碼進入,但出于安全的考慮我并不想告訴他密碼。
此時外賣小哥看到門禁有一個高級按鈕“一鍵獲取授權(quán)”,只要我這邊同意,他會獲取到一個有效期 2小時的令牌(token)正常出入。
令牌(token)和 密碼 的作用雖然相似都可以進入系統(tǒng),但還有點不同。token 擁有權(quán)限范圍,有時效性的,到期自動失效,而且無效修改。
二、OAuth2.0 授權(quán)方式
OAuth2.0 的授權(quán)簡單理解其實就是獲取令牌(token)的過程,OAuth 協(xié)議定義了四種獲得令牌的授權(quán)方式(authorization grant )如下:
- 授權(quán)碼(authorization-code)
- 隱藏式(implicit)
- 密碼式(password):
- 客戶端憑證(client credentials)
但值得注意的是,不管我們使用哪一種授權(quán)方式,在三方應用申請令牌之前,都必須在系統(tǒng)中去申請身份唯一標識:客戶端 ID(client ID)和 客戶端密鑰(client secret)。這樣做可以保證 token 不被惡意使用。
下面我們會分析每種授權(quán)方式的原理,在進入正題前,先了解 OAuth2.0 授權(quán)過程中幾個重要的參數(shù):
- response_type:code 表示要求返回授權(quán)碼,token 表示直接返回令牌
- client_id:客戶端身份標識
- client_secret:客戶端密鑰
- redirect_uri:重定向地址
- scope:表示授權(quán)的范圍,read只讀權(quán)限,all讀寫權(quán)限
- grant_type:表示授權(quán)的方式,AUTHORIZATION_CODE(授權(quán)碼)、password(密碼)、client_credentials(憑證式)、refresh_token 更新令牌
- state:應用程序傳遞的一個隨機數(shù),用來防止CSRF攻擊。
1、授權(quán)碼
OAuth2.0四種授權(quán)中授權(quán)碼方式是最為復雜,但也是安全系數(shù)最高的,比較常用的一種方式。這種方式適用于兼具前后端的Web項目,因為有些項目只有后端或只有前端,并不適用授權(quán)碼模式。
下圖我們以用WX登錄掘金為例,詳細看一下授權(quán)碼方式的整體流程。
用戶選擇WX登錄掘金,掘金會向WX發(fā)起授權(quán)請求,接下來 WX詢問用戶是否同意授權(quán)(常見的彈窗授權(quán))。response_type 為 code 要求返回授權(quán)碼,scope 參數(shù)表示本次授權(quán)范圍為只讀權(quán)限,redirect_uri 重定向地址。
- https://wx.com/oauth/authorize?
- response_type=code&
- client_id=CLIENT_ID&
- redirect_uri=http://juejin.im/callback&
- scope=read
用戶同意授權(quán)后,WX 根據(jù) redirect_uri重定向并帶上授權(quán)碼。
- http://juejin.im/callback?code=AUTHORIZATION_CODE
當掘金拿到授權(quán)碼(code)時,帶授權(quán)碼和密匙等參數(shù)向WX申請令牌。grant_type表示本次授權(quán)為授權(quán)碼方式 authorization_code ,獲取令牌要帶上客戶端密匙 client_secret,和上一步得到的授權(quán)碼 code。
- https://wx.com/oauth/token?
- client_id=CLIENT_ID&
- client_secret=CLIENT_SECRET&
- grant_type=authorization_code&
- code=AUTHORIZATION_CODE&
- redirect_uri=http://juejin.im/callback
最后 WX 收到請求后向 redirect_uri 地址發(fā)送 JSON 數(shù)據(jù),其中的access_token 就是令牌。
- {
- "access_token":"ACCESS_TOKEN",
- "token_type":"bearer",
- "expires_in":2592000,
- "refresh_token":"REFRESH_TOKEN",
- "scope":"read",
- ......
2、隱藏式
上邊提到有一些Web應用是沒有后端的, 屬于純前端應用,無法用上邊的授權(quán)碼模式。令牌的申請與存儲都需要在前端完成,跳過了授權(quán)碼這一步。
前端應用直接獲取 token,response_type 設置為 token,要求直接返回令牌,跳過授權(quán)碼,WX授權(quán)通過后重定向到指定 redirect_uri 。
- https://wx.com/oauth/authorize?
- response_type=token&
- client_id=CLIENT_ID&
- redirect_uri=http://juejin.im/callback&
- scope=read
3、密碼式
密碼模式比較好理解,用戶在掘金直接輸入自己的WX用戶名和密碼,掘金拿著信息直接去WX申請令牌,請求響應的 JSON結(jié)果中返回 token。grant_type 為 password 表示密碼式授權(quán)。
- https://wx.com/token?
- grant_type=password&
- username=USERNAME&
- password=PASSWORD&
- client_id=CLIENT_ID
這種授權(quán)方式缺點是顯而易見的,非常的危險,如果采取此方式授權(quán),該應用一定是可以高度信任的。
4、憑證式
憑證式和密碼式很相似,主要適用于那些沒有前端的命令行應用,可以用最簡單的方式獲取令牌,在請求響應的 JSON 結(jié)果中返回 token。
grant_type 為 client_credentials 表示憑證式授權(quán),client_id 和 client_secret 用來識別身份。
- https://wx.com/token?
- grant_type=client_credentials&
- client_id=CLIENT_ID&
- client_secret=CLIENT_SECRET
三、令牌的使用與更新
1、令牌怎么用?
拿到令牌可以調(diào)用 WX API 請求數(shù)據(jù)了,那令牌該怎么用呢?
每個到達WX的請求都必須帶上 token,將 token 放在 http 請求頭部的一個Authorization字段里。
如果使用postman 模擬請求,要在Authorization -> Bearer Token 放入 token,注意:低版本postman 沒有這個選項。
2、令牌過期怎么辦?
token是有時效性的,一旦過期就需要重新獲取,但是重走一遍授權(quán)流程,不僅麻煩而且用戶體驗也不好,那如何讓更新令牌變得優(yōu)雅一點呢?
一般在頒發(fā)令牌時會一次發(fā)兩個令牌,一個令牌用來請求API,另一個負責更新令牌 refresh_token。grant_type 為 refresh_token 請求為更新令牌,參數(shù) refresh_token 是用于更新令牌的令牌。
- https://wx.com/oauth/token?
- grant_type=refresh_token&
- client_id=CLIENT_ID&
- client_secret=CLIENT_SECRET&
- refresh_token=REFRESH_TOKEN
總結(jié)
OAuth2.0 授權(quán)其實并不是很難,只不過授權(quán)流程稍顯麻煩,邏輯有些繞,OAuth2.0它是面試經(jīng)常會被問到的知識點,還是應該多了解一下。
原文鏈接:https://mp.weixin.qq.com/s/in_E1pKqQc8wkPXT61g8gQ