點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺(tái)回復(fù)"書"，獲取

后臺(tái)回復(fù)“k8s”，可領(lǐng)取k8s資料

當(dāng)企業(yè)應(yīng)用系統(tǒng)逐漸增多后，每個(gè)系統(tǒng)單獨(dú)管理各自的用戶數(shù)據(jù)容易形成信息孤島，分散的用戶管理模式阻礙了企業(yè)應(yīng)用向平臺(tái)化演進(jìn)。當(dāng)企業(yè)的互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展到一定規(guī)模，構(gòu)建統(tǒng)一的標(biāo)準(zhǔn)化賬戶管理體系將是必不可少的，因?yàn)樗瞧髽I(yè)互聯(lián)網(wǎng)云平臺(tái)的重要基礎(chǔ)設(shè)施，能夠?yàn)槠脚_(tái)帶來統(tǒng)一的帳號(hào)管理、身份認(rèn)證、用戶授權(quán)等基礎(chǔ)能力，為企業(yè)帶來諸如跨系統(tǒng)單點(diǎn)登錄、第三方授權(quán)登錄等基礎(chǔ)能力，為構(gòu)建開放平臺(tái)和業(yè)務(wù)生態(tài)提供了必要條件。

—?1?—

名詞定義

• Third-party application：第三方應(yīng)用程序，本文中又稱“客戶端”（client）。

• HTTP service：HTTP服務(wù)提供商，本文中簡稱“服務(wù)提供商”。

• Resource Owner：資源所有者，本文中又稱“用戶”（user），即登錄用戶。

• User Agent：用戶代理，本文中就是指瀏覽器。

• Authorization server：認(rèn)證服務(wù)器，即服務(wù)提供商專門用來處理認(rèn)證的服務(wù)器。

• Resource server：資源服務(wù)器，即服務(wù)提供商存放用戶生成的資源的服務(wù)器。它與認(rèn)證服務(wù)器，可以是同一臺(tái)服務(wù)器，也可以是不同的服務(wù)器。

—?2?—

研發(fā)背景

單體應(yīng)用體系下，應(yīng)用是一個(gè)整體，一般針對(duì)所有的請(qǐng)求都會(huì)進(jìn)行權(quán)限校驗(yàn)。請(qǐng)求一般會(huì)通過一個(gè)權(quán)限的攔截器進(jìn)行權(quán)限的校驗(yàn)，在登錄時(shí)將用戶信息緩存到 session 中，后續(xù)訪問則從緩存中獲取用戶信息。

隨著 Restful API、微服務(wù)的興起，基于 Token 的認(rèn)證現(xiàn)在已經(jīng)越來越普遍。Token 和 Session ID 不同，并非只是一個(gè) key。Token 一般會(huì)包含用戶的相關(guān)信息，通過驗(yàn)證 Token 就可以完成身份校驗(yàn)。

基于 Token 認(rèn)證的優(yōu)勢(shì)如下：

• 服務(wù)端無狀態(tài)：Token 機(jī)制在服務(wù)端不需要存儲(chǔ) session 信息，因?yàn)?Token 自身包含了所有用戶的相關(guān)信息。

• 性能較好，因?yàn)樵隍?yàn)證 Token 時(shí)不用再去訪問數(shù)據(jù)庫或者遠(yuǎn)程服務(wù)進(jìn)行權(quán)限校驗(yàn)，自然可以提升不少性能。

• 支持移動(dòng)設(shè)備，支持跨程序調(diào)用，Cookie 是不允許垮域訪問的，而 Token 則不存在這個(gè)問題。

—?3?—

研發(fā)目標(biāo)

通過標(biāo)準(zhǔn)安全認(rèn)證流程，異構(gòu)系統(tǒng)或跨服務(wù)間能夠靈活地實(shí)現(xiàn)指定功能部件或服務(wù)的集成、統(tǒng)一的安全認(rèn)證。

基于 Token 認(rèn)證的一個(gè)典型流程如下：

用戶輸入登錄信息（或者調(diào)用 Token 接口，傳入用戶信息），發(fā)送到身份認(rèn)證服務(wù)進(jìn)行認(rèn)證（身份認(rèn)證服務(wù)可以和服務(wù)端在一起，也可以分離，看微服務(wù)拆分情況了）。

身份驗(yàn)證服務(wù)驗(yàn)證登錄信息是否正確，返回接口（一般接口中會(huì)包含用戶基礎(chǔ)信息、權(quán)限范圍、有效時(shí)間等信息），客戶端存儲(chǔ)接口，可以存儲(chǔ)在 Session 或者數(shù)據(jù)庫中。

客戶端將 Token 放在 HTTP 請(qǐng)求頭中，發(fā)起相關(guān) API 調(diào)用。

被調(diào)用的微服務(wù)，驗(yàn)證 Token 權(quán)限。

服務(wù)端返回相關(guān)資源和數(shù)據(jù)。

安全認(rèn)證功能點(diǎn)：

獲取憑證，第三方應(yīng)用客戶端使用客戶端編碼/安全碼、資源所有者用戶名/密碼等證件信息從授權(quán)服務(wù)器上獲取 Access Token 資源訪問憑證。

登錄授權(quán)，客戶端攜帶 Access Token 憑證訪問服務(wù)器資源，資源服務(wù)器驗(yàn)證 Token、第三方應(yīng)用憑證信息、資源所有者 User 合法性，通過 Token 讀取資源所有者身份信息（user）加載資源所有者的權(quán)限項(xiàng)執(zhí)行登錄。

訪問鑒權(quán)，第三方應(yīng)用客戶端訪問服務(wù)端資源，系統(tǒng)驗(yàn)證訪問者 Access Token 合法性、權(quán)限信息，驗(yàn)證憑證（Access Token）正確，此時(shí)資源服務(wù)器就會(huì)返回資源信息。

憑證續(xù)約，Access token 訪問憑證過期需要進(jìn)行憑證續(xù)約，刷新 Token 憑證有效期。

—?4?—

技術(shù)選型分析

• 系統(tǒng)授權(quán)采用 OAuth2 開放式授權(quán)標(biāo)準(zhǔn)密碼模式。

• Token 采用 JWT 標(biāo)準(zhǔn)。

OAuth 開放授權(quán)

OAuth（Open Authorization，開放授權(quán)）是為用戶資源的授權(quán)定義了一個(gè)安全、開放及簡單的標(biāo)準(zhǔn)，第三方無需知道用戶的賬號(hào)及密碼，就可獲取到用戶的授權(quán)信息。

主要的四種授權(quán)方式：

• 授權(quán)碼模式（authorization code）用在客戶端與服務(wù)端應(yīng)用之間授權(quán)碼。

• 簡化模式（implicit）用在移動(dòng) app 或者 web app（這些 app 是在用戶的設(shè)備上的，如在手機(jī)上調(diào)起微信來進(jìn)行認(rèn)證授權(quán)）。不通過第三方應(yīng)用程序的服務(wù)器，直接在瀏覽器中向認(rèn)證服務(wù)器申請(qǐng)令牌，跳過了“授權(quán)碼”這個(gè)步驟，因此得名。所有步驟在瀏覽器中完成，令牌對(duì)訪問者是可見的，且客戶端不需要認(rèn)證。

• 密碼模式（resource owner password credentials）應(yīng)用直接都是受信任的（都是由一家公司開發(fā)的）密碼模式中，用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向“服務(wù)商提供商”索要授權(quán)。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲(chǔ)存密碼。

• 客戶端模式（client credentials）用在應(yīng)用 API 訪問客戶端模式（Client Credentials Grant）指客戶端以自己的名義，而不是以用戶的名義，向“服務(wù)提供商”進(jìn)行認(rèn)證。嚴(yán)格地說，客戶端模式并不屬于 OAuth 框架所要解決的問題。在這種模式中，用戶直接向客戶端注冊(cè)，客戶端以自己的名義要求“服務(wù)提供商”提供服務(wù)，其實(shí)不存在授權(quán)問題。

Json Web Token（JWT）

Json Web Token（JWT），是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于 JSON 的開放標(biāo)準(zhǔn)（RFC 7519）。該 Token 被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場景。JWT 的聲明一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該 Token 也可直接被用于認(rèn)證，也可被加密。

—?5?—

認(rèn)證流程邏輯

系統(tǒng)授權(quán)

第三方應(yīng)用客戶端使用客戶端編碼/安全碼、資源所有者用戶名/密碼等證件信息從授權(quán)服務(wù)器上獲取 Access Token 資源訪問憑證。

系統(tǒng)授權(quán)頒發(fā)給客戶應(yīng)用 Access Token。

系統(tǒng)鑒權(quán)

客戶端攜帶 Access Token 憑證訪問服務(wù)器資源，資源服務(wù)器驗(yàn)證 Token、第三方應(yīng)用、資源所有者 User 合法性，通過 Token 讀取資源所有者身份信息（user）加載資源所有者的權(quán)限執(zhí)行登錄。

系統(tǒng)驗(yàn)證訪問者 Access Token 合法性、權(quán)限信息，驗(yàn)證憑證（Access Token）正確，此時(shí)資源服務(wù)器就會(huì)返回資源信息。

憑證續(xù)約

Access Token 訪問憑證過期需要進(jìn)行憑證續(xù)約，刷新 Token 憑證有效期。

—?6?—

接口設(shè)計(jì)

授權(quán)憑證

獲取授權(quán)憑證，校驗(yàn)客戶端身份信息、校驗(yàn)資源所有者身份信息，下發(fā) Token 憑證。

客戶端編碼/安全碼需要第三方應(yīng)用到系統(tǒng)注冊(cè)審核通過后生成。

授權(quán)憑證續(xù)約

獲取續(xù)約授權(quán)憑證，校驗(yàn)客戶端身份信息、校驗(yàn) RefreshToken 憑證，下發(fā) Token 憑證。

作者：mars

來源：https://juejin.cn/post/6906149001520037902

想知道更多？掃描下面的二維碼關(guān)注我后臺(tái)回復(fù)"技術(shù)"，加入技術(shù)群 后臺(tái)回復(fù)“k8s”，可領(lǐng)取k8s資料【精彩推薦】

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數(shù)據(jù)？

• 架構(gòu)之道：分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)

• 星巴克不使用兩階段提交

• 面試官：Redis新版本開始引入多線程，談?wù)勀愕目捶?#xff1f;

• 喜馬拉雅自研網(wǎng)關(guān)架構(gòu)演進(jìn)過程

• 收藏：存儲(chǔ)知識(shí)全面總結(jié)

• 微博千萬級(jí)規(guī)模高性能高并發(fā)的網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)

總結(jié)

以上是生活随笔為你收集整理的微服务架构统一安全认证设计与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。