[譯] 深刻 OAuth2.0 和 JWT

原文連接： uriotnews.com/?s=oauth2.0…

I. 認證和受權

從基於計算機的應用出現伊始，幾乎每一個開發者在其職業生涯內都會面對的一個最多見也是最複雜的問題，就是安全性（security）。這類問題意味着要考慮理解由誰提供什麼數據/信息，此外還有關乎時間、校驗、再校驗等諸如此類的不少其餘方面的事情。

而和安全性相關的全部關注點均可以被分解成兩類問題：認證（Authentication） 和 受權（Authorization）。

雖然這兩個術語經常交替着使用，但它們本質上表示了不一樣的功用。讓咱們試着擦亮記憶，再一次來定義這些概念。

認證

認證是這樣一種驗證過程：經過讓用戶、網站、應用程序經過提供合法證書或驗證方式，以證實他們符合本身所宣稱的身份。認證常常經過用戶名和密碼證明，有事也會輔以一些其餘的只爲用戶所知的信息。這類信息或元素稱爲因子（factors）。基於這些因子，任何認證機制均可以劃分爲如下三類：

1. 單因子認證: 只依賴用戶名和密碼
2. 雙因子認證: 除了用戶名和密碼，也須要一塊保密信息（好比銀行網站可能要求用戶輸入一個只有本身知道的 PIN）
3. 多因子認證 (MFA): 使用兩個或多個、來自不一樣類別的安全性因子（如醫院系統須要用戶名密碼 + 用戶智能手機收到的安全驗證碼 + 指紋信息）

受權

受權指的是一個驗證某用戶能訪問什麼的過程。在受權過程當中，某用戶/應用程序的權限級別被肯定後，才被容許訪問特定的 APIs/模塊。一般，受權發生在用戶身份被 認證 以後。

受權是經過使用「策略（policies）」和「規則（rules）」來實現的。

認證 vs 受權

雖然認證和受權經常交替着使用，但能夠試着用一個「蘇打水和雞尾酒」的比喻來理解：兩者殊爲不一樣 -- 蘇打水做爲一種原材料，能夠被用來製做多種不一樣的飲料，也能夠單獨飲用；而雞尾酒則是一種由多種成分構成的混合品，蘇打水也多是其中之一，但不會只包含這一種。

如此說來，說蘇打水等同於雞尾酒或雞尾酒就是冒泡的蘇打水都是不正確的。類似的是，認證和受權也不是一樣的術語；實現得好的話它們能夠相得益彰，但本質上是不一樣的。

	認證	受權
1	肯定用戶所宣稱的身份	肯定用戶可訪問的權限
2	經過合法憑證校驗用戶	經過規則和策略校驗訪問
3	早於受權	在認證成功後執行
4	經過 ID tokens 實現	用 Access Tokens 實現

在真實場景中，要結合使用認證和受權以保護資源。當你能證實本身的身份以前，不該該被容許訪問資源；而即便證實了身份，若無訪問權限，依然應被拒絕。

實現機制

要實現認證和受權有多種途徑，但時下最流行的是 「基於令牌（token-based）」 的方法。

什麼是基於令牌的認證？

基於令牌的認證和受權（Token-based authentication/authorization）是這樣一種技術：當用戶在某處輸入一次其用戶名和密碼後，做爲交換會獲得一個惟一輩子成的已加密令牌。該令牌隨後會替代登錄憑證，用以訪問受保護的頁面或資源。

這種方式的要點在於確保每一個發往服務器的請求都伴隨着一個已簽名的令牌，服務器利用該令牌覈驗真實性以後纔對當次請求作出響應。

令牌是什麼？

一個「令牌」就是服務器生成的一段數據，包含了惟一性識別一個用戶的信息，通常被生成爲一長串隨機字符和數字。

好比看起來可能像這樣：cc7112734bbde748b7708b0284233419 ，或更復雜些好比： eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJtZXNzYWdlIjoiSldUIFJ1bGVzISIsImlhdCI6MTQ1OTQ0ODExOSwiZXhwIjoxNDU5NDU0NTE5fQ.\-yIVBD5b73C75osbmwwshQNRC7frWUYrqa TjTpza2y4。

這個令牌自己是無心義和無用的，但結合適當的令牌化系統，就會變成保證應用安全性的重要一環。

爲什麼要使用令牌？

比之於傳統的 cookies 等手段，使用令牌有以下好處：

• 無狀態：令牌是自包含（self-contained）的，其包含了全部用於認證的信息。這對於可擴展性是極佳的，可讓服務器從不得不存儲 session 的境地中解脫
• 能夠在任何地方生成：令牌的生成和校驗是解耦的，讓使用單獨的服務器甚至不一樣的廠商來完成令牌的簽名成爲了可能的選項，如 Auth0（譯註：一家 ‘Identity-as-a-service’ 提供商）
• 細粒度的訪問控制：經過令牌負荷（token payload），不只是用戶可訪問的資源這一項，也能夠輕易制定更多用戶角色和權限

基於令牌的實現

儘管具體實現各有不一樣，但基本上都涉及如下步驟：

1. 用戶經過用戶名和密碼請求訪問
2. 應用驗證憑證
3. 應用向客戶端發放已簽名的令牌
4. 客戶端存儲令牌，並將其附加在其後的每次請求中一同發送
5. 服務器驗證令牌並響應數據

雖然說並沒有關於該如何實現你的應用的限制，但 IETF（Internet Engineering Task Force，互聯網工程任務組） 仍是定義了一些標準。其中最流行的有兩個：

1. OAuth 2.0 (RFC 6749 and RFC 6750).

2. JWT (RFC 7519).

II. 瞭解 OAuth 2.0

咱們已經刷新了關於認證和受權的認知，並將瞭解基於令牌認證的常識。在本章節中，來看看最經常使用的一種實現：OAuth 2.0。

OAuth 2.0 簡介

在傳統 C/S 模型中，客戶端（client）經過讓服務器認證資源擁有者（resource owner）的憑證來請求服務端受保護的資源。資源擁有者會將本身的憑證分享給第三方應用（third-party applications），讓後者得以訪問受限資源。這種憑證分享行爲會形成若干問題和限制，其中的一些以下所列：

• 第三方應用須要存儲資源擁有者的憑證以持續利用，典型的如存儲一個明文的密碼
• 儘管存在密碼固有的安全性弱點，服務器仍得支持密碼認證
• 對於資源擁有者的受限資源，第三方應用獲得了過於寬泛的訪問權限；置資源擁有者於無力約束訪問時長或限制訪問資源子集的境地
• 資源擁有者沒法撤回個別第三方的訪問權限，除非改變全部第三方的密碼

OAuth 針對這些問題提出了引入一個認證層，並把客戶端（client）的角色與資源擁有者的角色分離開來。因此：

OAuth 是一種受權協議，以容許用戶將對其在一個站點上的資源的受限訪問許可給另外一個站點，而沒必要公開其憑據

OAuth 爲客戶端提供一種「安全代理訪問」能力，用以表明資源擁有者訪問服務器資源。OAuth 指定了這樣一個過程：資源擁有者在不分享其憑證的前提下受權第三方訪問其服務器資源。

下面舉個例子來講明：

泊車鑰匙

你知道有些小轎車的「泊車鑰匙」吧？若是還不曾耳聞的話，那就是有些車型（沒錯，就是特別奢侈的那些！）附有一種特別的鑰匙，能夠在泊車時交給服務員。和你的正常鑰匙不一樣的是，這種鑰匙不容許汽車開出去一兩英里那麼遠。

某些泊車鑰匙打不開後備箱，另外一些則訪問不了車載電話的通信錄。不管此類限制是什麼，思路都是同樣清晰的：你讓某人經過特殊的鑰匙有限訪問你的車，但你的正常鑰匙能解鎖一切。

相似的，OAuth 中的「泊車鑰匙」就是 訪問令牌（Access Tokens），經過其容許對資源的不一樣級別的訪問。

OAuth 2.0 術語

角色（Roles）： OAuth2.0 規範定義了四種角色。

1. 資源擁有者 Resource Owner：一個有能力對訪問受保護資源受權的實體（entity）。當這個實體是一我的時，它就表示終端用戶（end-user）。
2. 資源服務器 Resource Server： 存儲受保護資源的服務器，能接受和響應使用訪問令牌的受保護資源請求。
3. 客戶端 Client：一個發起對受保護資源請求的應用程序，其表明了資源擁有者並持有其憑證。術語 「client」 並不意味着任何實現特徵（如該應用程序是否運行在服務器上、桌面端，或是其餘設備上）。
4. 受權服務器 Authorization Server：當資源擁有者認證成功並得到受權以後，該服務器向客戶端授予訪問令牌。

令牌（Tokens）： 令牌有兩種類型。

1. 訪問令牌 Access Token： 訪問令牌即表示頒發給客戶端之受權的一個字符串。對用戶端來講這個字符串通常是晦澀的。令牌表明了特殊的訪問範圍和持續時間，由資源擁有者授予，被資源服務器和受權服務器實施。

   令牌可能表示一個用來取回認證信息的標識符，也可能以一種可驗證的方式（如包含一些數據和簽名）自包含認證信息。

2. 更新令牌 Refresh Token： 更新令牌是用來得到訪問令牌的憑證。更新令牌由受權服務器向客戶端發出，並在當訪問令牌無效或過時後，用更新令牌得到一個新的訪問令牌；也可能用其得到訪問範圍相同或更窄的附加訪問令牌（這些訪問令牌和通過資源擁有者受權的訪問令牌相比，可能有更短的生存時間和更少的權限）。

   是否發放一個更新令牌是由受權服務器酌情處理的；若是發放了則會用在後續發放訪問令牌時。

不一樣於請求令牌，更新令牌專爲受權服務器設計，不會發送給資源服務器。

受權許可（Authorization Grant）： 受權許但是一種表示資源擁有者之承認（訪問其受保護資源）的憑證，被客戶端用於獲取訪問令牌。OAuth 2.0 規範定義了四種許可類型：

1. 受權代碼 Authorization Code: 受權代碼由使用一個做爲客戶端和資源擁有者之中間人的受權服務器處獲取。不一樣於從資源擁有者那裏直接請求受權，客戶端將資源擁有者引導至受權服務器，後者又將資源擁有者伴隨一個受權代碼引導回客戶端。
2. 隱式許可 Implicit Grant: 不向客戶端發送受權代碼，而是由客戶端直接獲取訪問令牌。
3. 資源擁有者密碼憑證 Resource owner password credentials (ROPC): 資源擁有者密碼憑證（如用戶名和密碼）可被直接做爲受權許能夠獲取訪問令牌。ROPC 只應被使用在資源擁有者和客戶端（如客戶端是所在設備操做系統的一部分，或是一個高權限的應用）之間須要高信任等級，且其餘幾種受權許可（如受權代碼）不可用的時候。
4. 客戶端憑證 Client Credentials: 當受權範圍限於客戶端控制之下的受保護資源，或是與受權服務器事先約定的受保護資源的時候，客戶端憑證（或其餘客戶端認證形式）可被用來做爲一種受權許可。典型的是客戶端表明本身（其同時也是資源擁有者）或客戶端正在請求訪問基於事先和資源服務器約定好的受保護資源的時候。

處理 OAuth 2.0 時理解這些術語是相當重要的。因此，也試着用一個例子來講明。

想象一個地鐵運輸系統。典型的引導流程以下：一位乘客（commuter）從售票機或售票窗口購買車票，制票系統許可這張車票在有限的時間或站點數量之間是合法的。然後，乘客在閘機驗票，車票合法則准許進入，便可乘坐列車。

用地鐵來比喻 OAuth

以上場景能夠和下面的 OAuth 2.0 中的角色對應起來：

乘客 (客戶端) 打算利用地鐵 (受保護的資源)，因此他/她得先向售票機或售票窗口 (資源服務器) 買票。制票系統 (受權服務器) 表明地鐵部門 (資源擁有者) 以車票 (令牌) 爲依據許可訪問。

用地鐵來比喻 OAuth

OAuth 2.0 控制流

一次 OAuth 2.0 的流程可用下圖表示:

OAuth 2.0 控制流

OAuth 2.0 用例

OAuth 2.0 把認證從受權決策中解耦。恰當設計的 OAuth 2.0 令牌既能夠支持細粒度受權，也能夠支持粗粒度受權。對於任何從另外一處（服務器/應用）訪問存儲在某處的資源/數據的場景，OAuth 2.0 可說是最適用的方法之一了。

如下列出一些場景，咱們將嘗試經過一個可穿戴設備的例子理解 OAuth 2.0 用例。

就拿運動手環來講吧，假設 Alice 買了一個，並用移動端上配套的手環 app 跟蹤並分析運動過程。那麼流程會是什麼樣呢？

• 首先，Alice 須要在手環 app 中建立我的檔案。一種方法是用手環 app 提供的檔案建立表單，另外一種方法是讓手環 app 訪問其餘 app 並拉取 Alice 已經存儲在那裏的檔案信息 -- 就拿 FriendBook 這個明顯是虛構的社交媒介網站來舉例吧。
• 手環 app 將重定向到 FriendBook 的登陸界面。一旦 Alice 成功使用其憑證登陸，她將看到一個准許贊成的頁面，詢問她或請她驗證她的哪些信息要分享，以及她容許訪問哪些存儲在 FriendBook 上的東西。在確認以後，手環 app 就可使用 OAuth 2.0 從 FriendBook 拉取並使用數據了。
• 可穿戴設備會向手環 app 發送數據，其後，手環 app 會同步數據到服務器，以期存檔和分析。

客戶端密碼： (儘管使用了 OAuth 2.0 的認證應該被避免). Alice 沒必要建立一個新密碼；取而代之的是，她使用本身在 FriendBook 服務器上已經建立的密碼。

Web 服務器： 可穿戴設備的 app 沒必要每次操做都發起登陸。Alice 要從 FriendBook 上分享或拉取數據，手環 app 將可以以服務器對服務器的方式訪問那些數據。

用戶代理： 手環 app 扮演了其應用服務器的代理人的角色，用來從主服務器上同步數據。因爲使用了 OAuth 2.0 對此受權，該代理能夠準確訪問服務器上的資源（數據）。

3. 瞭解 JWT

下面來看看 JWT。

JSON Web Token (JWT)，一般讀做 「jot」，是一個定義了以 JSON 對象緊湊而自包含的在各方之間安全傳輸信息的標準。其包含了聲明方面的信息，特別的被用於如 HTTP 等空間受約束的環境；該信息可被驗證，也是可信的，由於通過了數字化簽名。JWT 能夠用 密鑰（如 HMAC） 或 公鑰私鑰對（RSA 或 ECDSA） 簽名。

JWT 的兩個特性是：

• 緊湊 Compact： 由於其相對較小的尺寸，JWT 能夠藉由 URL 發送， 做爲一個 POST 參數，或在一個 HTTP header 內。
• 自包含 Self-contained： 一個 JWT 包含了全部關於一個實體的所需信息，以免屢次查詢數據庫。JWT 的接納者一樣無需調用服務器以驗證令牌。

這些令牌能夠是被簽名的、被加密的，或二者皆有。簽名過的令牌被用來驗證令牌完整性，而加密過的令牌用來隱藏聲明。

注意：正如名稱所暗示的，JWT 是 JSON 形式的，也就意味着其包含鍵值對。雖然說在 JSON 合法和有關方一致性方面，對鍵和值有多長並沒有限制，但大多數標準都遵循了 3個字母 的鍵格式。

JWT 術語

JWT 表現爲由點（.）分割的三個字符串組成的一個序列，典型的格式看起來以下：

AAAAA.BBBBB.CCCCC

三個子串分別稱做 頭部（Header） 、 負載（Payload） 和 簽名（Signature），下面逐一講解：

頭部 Header

雖然說只要相關幾方之間有共識，則在頭部中放什麼是沒有限制的，但一般由兩部分組成：

1. typ: 表示令牌類型（type），值爲 JWT
2. alg: 表示簽名此令牌的算法（algorithm），如 HMAC、RSA、SHA

負載 Payload

JWT 的第二部分表示負載，這部分由聲明（claims）組成。

所謂聲明就是關於實體和任意附加數據的信息。在一段 JWT 中，聲明由鍵表示。這些聲明是依賴上下文的，且應該相應的被處理和被理解，但依每種規範會有若干標準規則應用於聲明：

1. 在一個 JWT 聲明集合中，每一個聲明的名稱必須是惟一的
2. 對於 JWT 的處理邏輯，必須 保證這種惟一性，要麼拒絕重複的名字，要麼用一個 JSON 處理器返回重複項中詞法上最後一個名字
3. 使用 JWT 的應用要明確其選用的聲明標準，並定義必須項和可選項
4. 由於 JWT 的核心目標之一就是精簡，故全部名字也應該簡短

一個可能的負載例子：

{ 
    "sub": "1234567890", "name": "Alice", "admin": true
}
複製代碼

負載中的聲明又能夠細分爲如下三種類型：

已註冊的聲明

有一些聲明註冊在 IANA(dzone.com/refcardz/co…) 的 「JSON Web 令牌聲明」 註冊表中。這些聲明並不是是在全部狀況下都要求強制使用或實現的，準確的說它們是做爲提供一個有用的集合的起始點而被註冊的。

其中一些有必要了解的是：

1. iss (issuer): 聲明瞭發行人，也就是發行 JWT 的主體。處理此聲明一般是因應用而異的。「iss」 值是一個大小寫敏感的字符串，包含一個普通字符串或者一個 URL。該聲明是可選的
2. sub (subject): 表示 JWT 的主體 (用戶)。值必需要麼是全局惟一的，要麼在發行人上下文範圍內局部惟一。處理該聲明一般也是因應用而異的。「sub」 值是一個大小寫敏感的字符串，包含一個普通字符串或者一個 URL。該聲明是可選的
3. aud (audience): 表示 JWT 的目標接收方。若是當該聲明存在且處理該聲明的一方不能經過 「aud」 的值進行自我身份驗證時，則 JWT 必須被拒絕。大多數狀況下，這個值是由大小寫敏感的字符串（包含一個普通字符串或者一個 URL）組成的數組。該聲明是可選的
4. exp (expiration): 表示過時時間，即等於或晚於那個時刻再處理 JWT 則毫不可被接受。其值一般是以秒記的時間戳（譯註：按 POSIX 中定義的 「seconds since epoch」 標準，也就是 PHP 等語言中經常使用的那種）。該聲明是可選的
5. nbf (not before) : 表示一個時間，即早於那個時刻再處理 JWT 則毫不可被接受。 其值一般是以秒記的時間戳。該聲明是可選的
6. iat (issued at): 表示發出 JWT 的時刻。可用於判斷 JWT 的壽命。必須是一個時間戳。該聲明是可選的
7. jti (JWT ID): 爲 JWT 提供一個惟一的身份識別符，其值必須難以重複，以防 JWT 被重複執行。該聲明是可選的

公開聲明

此類聲明的名字可被 JWT 使用者任意定義。但爲了預防衝突，任何新名字都應該註冊在 IANA 「JSON Web Token Claims」 註冊表中，或將其定義爲包含防衝突命名空間的 URI 等。

在任何狀況下，對名字和值的定義都要考慮到合理的預防措施，以確保它們在其定義的命名空間中受控。

私有聲明

這能夠理解爲是建立自定義聲明以在應用內共享信息規格，能夠是除以上兩種外的任意聲明名字。與公有聲明不一樣，私有聲明受制於衝突問題，要當心使用。

簽名

簽名先是經過對頭部和負載 Base64 編碼而生成，其後會與一個密鑰聯合，最好被頭部中指定的算法簽名。

簽名被用於校驗 JWT 的發送者是否名實相符，以及信息在傳送過程當中是否被更改。好比，若是建立了一個使用 HMAC SHA256 算法之令牌的簽名，你會像下面這樣作：

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
複製代碼

一個更完整的例子

觀察以下 JWT 簽名：

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzYXRpc2giLCJhdWQiOiJteWFwcCIsIkNVU1QiOiIxIiwiZXhwIjoxNTY2MjE0NTg1LCJpc3MiOiJhdXRoLWFwcCJ9.WknG6jiM_vAaflLnKyjlXh5BrM4MUJR9dFrVx-XE3zRVWiyXeIVzI-OomFh0vVHRwrK3-Tttg0HyKBTnCA3mSg
複製代碼

該簽名使用了 HS512 算法編碼，幷包含了以下信息：

Header: { 
    "alg": "HS512", 
    "typ": "JWT"
} 
Payload: { 
    "sub": "satish", 
    "aud": "myapp", 
    "CUST": "1", 
    "exp": 1566214585, 
    "iss": "my-auth-app"
}
複製代碼

JWT 用例

認證

當用戶使用其憑證成功登陸後，一個 ID 令牌會被返回。按照 OpenID Connect (OIDC) 規範，該 ID 令牌就是一個 JWT。

受權

一旦用戶登陸成功，應用就可能會表明用戶請求訪問路由、服務、資源等。爲此，將使用一個訪問令牌，形式上可能就是 JWT。每一個後續的請求也都包含該訪問令牌。因爲 JWT 開銷很小，也能輕易用於跨域名訪問，單點登陸（SSO，Single Sign-on）普遍使用這項技術。

信息交換

因爲可被簽名，JWT 是一種在多方間安全傳遞信息的良好方式，這意味着你能肯定發送者名實相符。另外，一個 JWT 結構容許你驗證內容沒有被篡改過。

爲什麼使用 JWT ？

解耦

JWT 最大的優點（比之於使用內存內隨機令牌的用戶 session 管理）就是其使得對第三方服務器認證邏輯的代理能夠：

• 一個集中式的、內部自定義開發的認證服務器
• 更典型的是，使用 LDAP 這種能夠發出 JWT 的商業產品
• 甚至可使用一個純第三方的認證提供商

認證邏輯/服務器能夠從應用服務器徹底分離，無需在應用間再分享密碼摘要。

無狀態

因爲 JWT 是自包含的，且無需在內存中保持請求之間的令牌，因此應用服務器能夠作到徹底無狀態（stateless）。認證服務器能夠頒發令牌，將其發回後就當即丟棄掉。

緊湊

JSON 比 XML 簡介，因此當其被編碼後，一個 JWT 比 SAML 令牌更小。這使得 JWT 成爲一個在 HTML 和 HTTP 環境中傳送的好選擇。

更安全

爲了簽名，JWT 可使用一個公鑰/私鑰對，表現爲 X.509 證書的形式。一個 JWT 也能夠經過分享使用了 HMAC 算法的密鑰而被對稱簽名。同時雖然 SAML 令牌也可使用 JWT 這樣的公鑰/私鑰對，但相比於簽名 JSON 的簡單性，想用 XML 數字簽名算法簽名 XML 卻不會引入未知的安全漏洞是很是困難的。

更通用

由於直接映射到對象，JSON 處理器在大多數編程語言中都更常見。相反，XML 沒有天然的 文檔到對象 的映射。這意味着 JWT 比 SAML 更易用。

更易處理

JWT 爲互聯網規模而設計，意思就是其在用戶設備上更易處理，特別是移動端。

JWT：要考慮到的點

除去以上說過的優缺點，JWT 標準也有其自身的問題：

• 若是須要封鎖或凍結一個用戶帳號，應用就不得不等待令牌過時才能徹底停工。
• 若是用戶要更新密碼（例如在帳戶劫持的狀況下）且一個認證在以前已經被執行過的話，那麼由以前的密碼產生的令牌會在過時前持續有效。
• 在標準實現中，沒有「更新」令牌被指定。所以過時後用戶將從新認證。
• 在不違背 JWT 令牌的「無狀態」方面的前提下，是不可能破壞一個令牌的，即使令牌已從瀏覽器被刪除，它也會在過時前一直有效。

爲了應對這些調整，一些 JWT 庫在標準實現之上增長了一個層，並容許更新令牌機制，同時也包含一些特性如在必要狀況下強制用戶從新認證等。

JWT：最佳實踐

在動手實現 JWT 以前，讓咱們瞭解一些最佳實踐，以確保基於令牌的認證恰當地用於你的應用中。

1. 保證安全。簽名 key 應該同其餘任何憑證同樣被處理，並只出示給必須須要它的服務。
2. 不要在負載中加入敏感信息。令牌被簽名爲難操做易解碼的形式。向負載中添加最少的聲明以保證性能和安全性。
3. 給令牌設置過時時間。技術上來講，一旦令牌被簽名 -- 它就是永久有效的，除非用來簽名的 key 改變，或明確的設置了過時時間。這會形成隱患，因此應該有令牌的過時、撤銷策略。
4. 擁抱 HTTPS。不要向非 HTTPS 的鏈接發送令牌，由於那些請求能夠被攔截從而連累到令牌。
5. 考察你全部的受權用例。增長一個次要的令牌驗證系統以確保令牌能從你的服務器上生成，舉例來講，也許不是通用作法，但可能對實現需求是很必要的。

更多

用 Spring Boot 2 和 JWT 實現基於角色的訪問控制

--End--

搜索 fewelife 關注公衆號

轉載請註明出處