前端網(wǎng)絡高級篇(二)身份認證

網(wǎng)絡身份的驗證的場景非常普遍,比如用戶登陸后才有權限訪問某些頁面或接口拜鹤。而HTTP通信是無狀態(tài)的框冀,無法記錄用戶的登陸狀態(tài),那么敏簿,如何做身份驗證呢明也?

下面,會從淺入深惯裕,陸續(xù)介紹幾種常用的認證方式和相關概念温数。文章較長,請耐心閱讀蜻势。

1. 鑒權與授權

  • 鑒權 Authentication撑刺,指對于一個聲明者所聲明的身份權利,對其所聲明的真實性進行鑒別確認的過程握玛。
    例子:用戶名張三够傍,密碼******次员,用戶名和密碼通過挖財驗證,登陸成功
  • 授權 Authorization王带,一般是指獲取用戶的委派權限淑蔚。
    例子:我是張三,有權訪問git/client/jizhang愕撰,因為gitlab給我進行了授權
image

一般流程為先鑒權再授權刹衫。而身份驗證指的就是鑒權這個步驟。

1.2 常用的鑒權方式

  • 方式一:HTTP Basic Authentication (401)
    客戶端發(fā)送http request 給服務器,服務器驗證該用戶是否已經(jīng)登錄驗證過了搞挣,如果沒有的話带迟,服務器會返回一個401 Unauthozied給客戶端,并且在Response 的 header “WWW-Authenticate” 中添加信息囱桨。
    然后仓犬,瀏覽器彈出輸入框要求輸入用戶名和密碼。

    image

    用戶輸入正確的用戶名和密碼后舍肠,瀏覽器用BASE64編碼搀继,放在Authorization header中發(fā)送給服務器。如下圖:
    image

    最后翠语,服務器將Authorization header中的用戶名密碼取出叽躯,進行驗證, 如果驗證通過肌括,將根據(jù)請求点骑,發(fā)送資源給客戶端。

  • 方式二:Session-cookie

  • 方式三:Token

  • 方式四:OAuth(開發(fā)授權)

后三種驗證方式下面逐漸展開講解谍夭。

2. Token VS Cookies

image

2.1 Cookies

Cookies是傳統(tǒng)的鑒權方式黑滴,通過瀏覽器攜帶的Cookies字段來進行狀態(tài)存儲。特點如下:

  • 認證信息在服務端需要存儲紧索。cookies攜帶sessionId袁辈,用戶經(jīng)過認證之后,應用都要在服務端做一次記錄齐板,以方便用戶下次請求的鑒別吵瞻。session的保存方法多種多樣,可以保存在文件中甘磨,也可以內存里橡羞,或第三方媒介,比如redis或者mongodb济舆。隨著認證用戶的增多卿泽,服務端的開銷會明顯增大。缺點
  • 一般不需要客戶端存儲。服務端通過reponse: Set-Cookie頭信息為客戶端設置cookie签夭,客戶端不需要做特殊配置齐邦,瀏覽器會在后續(xù)的ajax請求中自動帶上cookie。
    image
  • 有CSRF(跨站點偽造請求)風險第租。缺點
  • 移動端用在使用cookie時有各種不便利和局限措拇。缺點
  • Cookie可以在同一域名下或者同一主域不同子域下共享,一旦跨主域慎宾,就無法共享缺點
  • 分布式應用上丐吓,可能會限制負載均衡器的能力。用戶認證之后趟据,服務端做認證記錄券犁,如果認證的記錄被保存在內存中的話,這意味著用戶下次請求還必須要請求在這臺服務器上,這樣才能拿到授權的資源汹碱,這樣在分布式的應用上粘衬,相應的限制了負載均衡器的能力。這也意味著限制了應用的擴展能力咳促。缺點

2.2 Token

Token是服務端生成的一串字符串稚新,以作客戶端進行請求的一個令牌,當?shù)谝淮蔚卿浐蟮茸海掌魃梢粋€Token便將此Token返回給客戶端枷莉,以后客戶端只需帶上這個Token前來請求數(shù)據(jù)即可,無需再次帶上用戶名和密碼尺迂。

最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)冒掌、sign(簽名噪裕,由token的前幾位+鹽以哈希算法壓縮成一定長的十六進制字符串,可以防止惡意第三方拼接token請求服務器)股毫。

相比Cookies膳音,Token的優(yōu)勢明顯多了蛹疯。

  • 服務端無需存儲認證信息承绸。因為Token本身就存儲了認證信息耻蛇。
  • 需要前端存儲(建議用localstorage)芋忿』派辏客戶端通過request: Authorization頭信息設置Token泊柬,發(fā)給服務端做驗證汤功。缺點
    image
  • 無CSRF風險
  • 適合移動端身份認證
  • token支持各類跨域

Javascript支持Token如下:

// JS
var res = new XMLHttpRequest();
...
req.setRequestHeader('Authorization',accesstoken);
  
// JQuery
$.ajax({
   url: api,
   type: "GET",
   headers: { "Authorization": "Bearer " + token}
})

2.3 什么是JWT(Json web token)

JWT是實現(xiàn)Web應用會話管理的一種方式姜骡。廣義上來講宣肚,它是一種開發(fā)標準想罕,而非技術實現(xiàn)(大部分的語言平臺都有按照它規(guī)定的內容提供了自己的技術實現(xiàn));狹義上講霉涨,它就是用來傳遞的Token字符串按价。

看一下JWT是如何傳遞的惭适。


image

它長得像下面這樣。楼镐。癞志。


image

JWT是如何對信息簽名加密的呢?
要前面的信息分為三部分:header框产,payload和signature凄杯。

  • header:說明這個JWT簽發(fā)的時候所使用的簽名和摘要算法
{
  "typ": "JWT",
  "alg": "HS256"
}
  • payload:用來承載要傳遞的數(shù)據(jù)
{
  "sub": "1234567890",
  "name": "john Doe",
  "admin": true
}
  • signature:密鑰

簽名過程:把headerpayload對應的json結構進行base64url編碼之后得到的兩個串用英文句點號拼接起來,然后根據(jù)header里面alg指定的簽名算法生成出來的茅信。函數(shù)如下:

HMACSH256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

image

HMAC計算:https://1024tools.com/hmac

下面的內容都是基于Token認證

3. Token有效期

顯而易見盾舌,身份驗證必須要有有效期!那么蘸鲸,如何在”用戶無感知”的情況下處理Token失效妖谴?

  • 方案一: 服務器端保存 Token 狀態(tài),用戶每次操作都會自動刷新(推遲) Token 的過期時間酌摇。
    • 缺點:請求次數(shù)多時膝舅,每次都刷新過期時間代價較大
  • 方案二:refresh token
    • 優(yōu)點:服務端不需要刷新token,避免頻繁讀寫操作

那讓我們看看什么是refresh token窑多?

3.1 Refresh token

第一步仍稀,登陸。


image

第二步埂息,業(yè)務請求


image

第三步技潘,Token過期,刷新Token


image

那么千康,如果refresh token也過期呢享幽?好吧,請重新登陸吧拾弃。

3.2 Refresh token自動續(xù)期

可以在Refresh token每次使用時值桩,更新它的過期時間。也可以在創(chuàng)建Refresh token時豪椿,就指定它的過期時間奔坟,比如,距離創(chuàng)建時間XXX天后過期搭盾。

看到這里咳秉,大家應該覺得身份驗證可以完美收官了。增蹭。滴某。但是,前面所講的技術都有一個大前提,就是霎奢,認證服務和業(yè)務服務在一起的户誓。
比如,上淘寶網(wǎng)幕侠,用淘寶賬號登陸帝美,沒有問題。
但是晤硕,現(xiàn)在很多網(wǎng)站都沒有自己的賬號密碼悼潭,而是通過第三方賬號登陸,比如微信舞箍,微博舰褪,QQ。

這種認證服務和業(yè)務服務分離的情況下疏橄,如何做身份認證呢占拍?繼續(xù)下面兩節(jié)吧!

4. 分離認證服務

認證服務和業(yè)務服務分離時捎迫,利用Token的無狀態(tài)特性晃酒,實現(xiàn)單點登陸。

第一步窄绒,登錄和業(yè)務請求


image

第二步贝次,更新Token

image

這樣好像完美多了。但是彰导,又有個問題蛔翅,上圖是在認證服務器信任業(yè)務服務器的場景下工作的。

問題1:如何處理不受信任的業(yè)務服務器呢位谋?
答案:使用非對稱加密簽名搁宾,認證服務器使用密鑰A簽發(fā)(私鑰),業(yè)務服務器使用密鑰B驗證(公鑰)倔幼。

問題2: 多個業(yè)務服務器之間使用相同的Token對用戶來說是不安全的!K损同!任何一個服務器拿到Token都可以仿冒用戶去另一個服務器處理業(yè)務,怎么處理鸟款?
答案:認證服務器產生Token時膏燃,需要把使用方-業(yè)務服務器相關信息記錄在Token中。

問題3:如果用戶不信任業(yè)務服務器呢何什?
答案:讓『認證服務』幫助用戶甄別『業(yè)務服務』组哩!

開發(fā)式API可以解決上面的所有問題。

5. 開放式API - OAuth

OAuth 2.0是一個關于授權(authorization)的開放網(wǎng)絡標準。

image

認證服務器不公開公鑰伶贰, 業(yè)務服務需要在認證服務注冊蛛砰,通過審核,拿到特定公鑰黍衙。
然后泥畅,用戶通過認證服務器授權,將授權數(shù)據(jù)加密到Token中琅翻。

OAuth有四個角色:

  • 資源擁有者(Resource Owner) - 用戶
  • 客戶端(Client) - 三方應用
  • 資源服務器(Resource Server) - 存放用戶資源和信息
  • 授權服務器(Authorization Server) - 給三方頒發(fā)授權令牌(access token)

授權流程如下圖:


image
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末位仁,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子方椎,更是在濱河造成了極大的恐慌聂抢,老刑警劉巖,帶你破解...
    沈念sama閱讀 211,042評論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件棠众,死亡現(xiàn)場離奇詭異琳疏,居然都是意外死亡,警方通過查閱死者的電腦和手機摄欲,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,996評論 2 384
  • 文/潘曉璐 我一進店門轿亮,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人胸墙,你說我怎么就攤上這事我注。” “怎么了迟隅?”我有些...
    開封第一講書人閱讀 156,674評論 0 345
  • 文/不壞的土叔 我叫張陵但骨,是天一觀的道長。 經(jīng)常有香客問我智袭,道長奔缠,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,340評論 1 283
  • 正文 為了忘掉前任吼野,我火速辦了婚禮校哎,結果婚禮上,老公的妹妹穿的比我還像新娘瞳步。我一直安慰自己闷哆,他們只是感情好,可當我...
    茶點故事閱讀 65,404評論 5 384
  • 文/花漫 我一把揭開白布单起。 她就那樣靜靜地躺著抱怔,像睡著了一般。 火紅的嫁衣襯著肌膚如雪嘀倒。 梳的紋絲不亂的頭發(fā)上屈留,一...
    開封第一講書人閱讀 49,749評論 1 289
  • 那天局冰,我揣著相機與錄音,去河邊找鬼灌危。 笑死康二,一個胖子當著我的面吹牛,可吹牛的內容都是我干的乍狐。 我是一名探鬼主播赠摇,決...
    沈念sama閱讀 38,902評論 3 405
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼浅蚪!你這毒婦竟也來了藕帜?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 37,662評論 0 266
  • 序言:老撾萬榮一對情侶失蹤惜傲,失蹤者是張志新(化名)和其女友劉穎洽故,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體盗誊,經(jīng)...
    沈念sama閱讀 44,110評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡时甚,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,451評論 2 325
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了哈踱。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片荒适。...
    茶點故事閱讀 38,577評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖开镣,靈堂內的尸體忽然破棺而出刀诬,到底是詐尸還是另有隱情,我是刑警寧澤邪财,帶...
    沈念sama閱讀 34,258評論 4 328
  • 正文 年R本政府宣布陕壹,位于F島的核電站,受9級特大地震影響树埠,放射性物質發(fā)生泄漏糠馆。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,848評論 3 312
  • 文/蒙蒙 一怎憋、第九天 我趴在偏房一處隱蔽的房頂上張望又碌。 院中可真熱鬧,春花似錦绊袋、人聲如沸赠橙。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,726評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至掉奄,卻和暖如春规个,著一層夾襖步出監(jiān)牢的瞬間凤薛,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,952評論 1 264
  • 我被黑心中介騙來泰國打工诞仓, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留缤苫,地道東北人。 一個月前我還...
    沈念sama閱讀 46,271評論 2 360
  • 正文 我出身青樓墅拭,卻偏偏與公主長得像活玲,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子谍婉,可洞房花燭夜當晚...
    茶點故事閱讀 43,452評論 2 348