OAuth 2.0系列（六）--- OAuth令牌

本章要解決的疑問：

• OAuth令牌是什么？

• 如何生成結構化的令牌（JWT）？

• 如何使用JOSE保護令牌數據？

• 如何通過令牌內省實時獲取令牌數據？

• 如何撤回令牌？

• 令牌的生命周期是怎樣的？

一、OAuth令牌是什么？

 令牌是OAuth中的核心組件，它代表了一次授權的結果，包含了資源擁有者、授權服務器、客戶端、受保護資源、權限范圍等信息，就像考駕照一樣，為了拿到最終的那張本本，你可能要經過科一到科四的重重考驗。在OAuth系統中，不同服務器對令牌的使用規則各有不同：

• 客戶端：客戶端只需要獲取到令牌並使用它，無需理解令牌所包含的信息，令牌對它是不透明的。
• 授權服務器：授權服務器需要頒發令牌，令牌的內容和規則都是它生成的，所以它是最了解令牌的一方。
• 資源服務器：資源服務器因為需要驗證令牌的正確性，所以也需要知道令牌的內容。

二、結構化令牌：JWT

在前面介紹的授權碼流程中，訪問令牌是一串隨機串，不代表任何信息，只是因為保存在共享數據庫中，可以提供以它為檢索值，查詢其他信息的功能，但是如果一個授權服務器對應多個資源服務器，再使用共享數據庫就不太合理了。

舉個例子🌰  ：

比如一家雲計算廠商提供了雲主機、雲硬盤、雲數據庫等資源，假設有個網關且提供授權服務器的功能，一個客戶端要想訪問這些資源需要先從網關獲取訪問令牌，在這種情況下不可能為了讓讓雲主機、雲硬盤和雲數據庫都能直接訪問令牌，就它們共享同一個數據庫，這是非常荒誕的做法。那么這種場景該怎么解決呢？答案是：結構化令牌和令牌內省。結構化令牌的實現方式是將所有必要的信息都放在令牌內部，使授權服務器可以通過令牌間接地和資源服務器進行通信，而不需要調用任何授權服務器端的API。前面提到過，結構化令牌的實現方式有SAML和JWT兩種，本文只介紹JWT，SAML屬於另一種協議。

2.1 JWT的結構

聲明：JWT的知識點很多，本文只介紹它的基本生成和使用原理，深度學習可以閱讀其官方文檔：https://jwt.io/ 

JWT，即JSON Web Token，提供了一種在令牌中攜帶信息的簡單方法。JWT的核心是將一個JSON對象封裝為一種用於網絡傳輸的格式。訪問官網可以生成一個JWT：

 

上圖是在官網生成的一個JWT，修改右側的內容，左側內容也會發生變化，從圖中的Decoded部分可以看出，JWT由頭部Header、荷載PayLoad和簽名Sign 三部分組成，而且三部分之間使用.進分割，JWT一般對簡單的形式是未簽名的token，就是上圖中去掉簽名密鑰之后的結果。而且每一部分都有自己的生成規則：

• Header：JSON對象，用於描述剩余部分的信息。其中typ代表第二部分PayLoad的類型，比如上圖中的JWT；alg代表第三部分的簽名算法，比如上圖中的HS256。在JWT中要對該JSON對象進行Base64URL編碼。
• PayLoad：JSON對象，存放用戶數據以及令牌信息，與Header相同，要對該JSON對象進行Base64URL編碼。
• Sign：如圖中所示，簽名的方式是分別對Header和PayLoad進行Base64URL編碼，再用句點符號.分割，最后使用密鑰進行簽名。

所以一個簽名的JWT的構成方式為：

base64url(header).base64url(payLoad).sign(base64url(header).base64url(payLoad).secret)

2.2 聲明JWT

除了一般的數據結構之外，JWT還提供了一組聲明，可以在不同的應用中通用，且所有字段都是可選項

除了上圖中給出的標准聲明外，開發過程中，還可以自定義所需的其他字段，如用戶名userName，角色role等。

2.3 在服務器上實現JWT

 JWT在授權服務器頒發，在客戶端服務器使用，在資源服務器驗證。

2.3.1 授權服務器頒發

授權服務器需要提供獲取jwt的方法，雖然JWT也是token，但最好和之前獲取不表示任何信息的的token區分，假設為/exchangeJwt。授權服務器一般會調用jwt第三方庫，只需自定義聲明的值即可，代碼如下：

public String jwtWithHs256(String sub, String[] aud, String jid) throws JoseException {
        JsonWebSignature jws = new JsonWebSignature();
        //設置Header 
        jws.setHeader("alg","HS256");
        jws.setHeader("typ","JWT");
        jws.setHeader("kid","ABCDEFG");
        //設置PayLoad
        JwtClaims jwtClaims = new JwtClaims();
        jwtClaims.setIssuer("me");
        jwtClaims.setSubject(sub);
        jwtClaims.setAudience(aud);
        jwtClaims.setExpirationTime(NumericDate.fromSeconds(2 * 60 * 60));
        jwtClaims.setNotBefore(NumericDate.now());
        jwtClaims.setIssuedAt(NumericDate.now());
        jwtClaims.setJwtId(jid);
        jws.setPayload(jwtClaims.toJson());
        //設置簽名key:最小長度為256位
        jws.setKey(new HmacKey(SECRET.getBytes()));
        return jws.getCompactSerialization();
    }

這樣就能返回一個使用HS256簽名的JWT，結果如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IkFCQ0RFRkcifQ.eyJpc3MiOiJtZSIsInN1YiI6InpoYW5nc2FuIiwiYXVkIjoiaHR0cHM6Ly9yZXNvdXJjZWVuZHBvaW50LmNvbS91c2VySW5mbyIsImV4cCI6NzIwMCwibmJmIjoxNjM2NDM4OTQxLCJpYXQiOjE2MzY0Mzg5NDEsImp0aSI6ImRmZGZkYWhrZmRoYXRlYXJlYXIifQ.YrJK74vkMOV2SFn3pNeuk2qoz4RGRDuwc4X9dyLsR94

將這個JWT復制到JWT在線生成工具之后結果如下：

 上圖中除了簽名校驗失敗之外，Header和PayLoad中的值都與在代碼中設置的值完全一致，簽名失敗的問題只需輸入頒發時的密鑰即可，如下圖：

 接下來，客戶端就能拿着JWT去請求資源服務器了。

2.3.2 客戶端服務器使用

上面的令牌中設置了過期時間，但是客戶端不用關心這個時間，只要將返回的jwt發送給資源服務器即可，資源服務器會對其進行校驗，如果校驗結果中提示jwt已過期，則客戶端重新獲取可用的jwt重新請求即可。請求方式與token方式一樣，使用Authorization：Bearer請求頭，請求如下：

curl --location --request GET 'https://resourceendpoint.com/userInfo' \
--header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IkFCQ0RFRkcifQ.eyJpc3MiOiJtZSIsInN1YiI6InpoYW5nc2FuIiwiYXVkIjoiaHR0cHM6Ly9yZXNvdXJjZWVuZHBvaW50LmNvbS91c2VySW5mbyIsImV4cCI6NzIwMCwibmJmIjoxNjM2NDM4OTQxLCJpYXQiOjE2MzY0Mzg5NDEsImp0aSI6ImRmZGZkYWhrZmRoYXRlYXJlYXIifQ.YrJK74vkMOV2SFn3pNeuk2qoz4RGRDuwc4X9dyLsR94'

2.3.3 資源服務器驗證

 資源服務器接收到上面的請求之后，先從Bearer中解析出JWT，然后按照頒發時的逆向流程進行解析，取出PayLoad，並驗證里面內容，驗證通過就能返回客戶端請求的資源了。驗證方法也很簡單，jose提供了驗證方法：

    public Boolean jwtWithHs256Verify(String jwt) throws JoseException {
        JsonWebSignature jsonWebSignature = new JsonWebSignature();
        jsonWebSignature.setCompactSerialization(jwt);
        jsonWebSignature.setKey(new HmacKey(SECRET.getBytes()));
        return jsonWebSignature.verifySignature();
    }

三、令牌的保護：JOSE

JOSE（JSON Object Signature and Encryption）即JSON對象的簽名與加密標准。這套規范以JSON為基礎數據模型，提供了簽名（JSON Web 簽名，簡稱JWS）、加密（JSON Web 加密，簡稱JWE）以及密鑰存儲格式（JSON Web 密鑰，簡稱JWK）的標准

3.1 使用HS256的對稱簽名

 對稱簽名的實現方式中，授權服務器和資源服務器使用共享密鑰，授權服務器進行簽名，資源服務器驗證簽名，在上文的例子中使用的就是HS256對稱簽名，這里不再贅述。需要注意的一點是：因為使用的是公共密鑰，所以授權服務器和資源服務器都能生成令牌！

3.2 使用RS256的非對稱簽名

 使用RS256算法時（底層使用的是RSA算法），授權服務器會擁有一對密鑰對：公鑰和私鑰，授權服務器使用私鑰加密，資源服務器從授權服務器獲取公鑰，用於驗證令牌，但是因為獲取不到私鑰，也就無法生成令牌！

首先，需要在授權服務器上添加一對公鑰和私鑰。

public String jwk() throws JoseException {
        return RsaJwkGenerator.generateJwk(2048).toJson(JsonWebKey.OutputControlLevel.INCLUDE_PRIVATE);
    }

返回格式如下：

{
    "kty": "RSA",
    "n": "sM1GB03U8yzrCkPSw7lAmwfhZtQ3q0w72yx4ydPcbvAvasKSoDB-tAaec_rHfaRzKiQNsTzmA0FQbk625mOXY9lClzT5J9P8XmqhUIlEqH04-PLsizqvWFoKlfsFwv4GEh-k2w3VAo9XBDHtnkThnugbvsM8QOGtBpZ-cN5oiXe9jb-ljUawtqjCk39idLc6mPogEC-uipYe0Aiv_W79WSZ8RtOuh3R8_RN8Sr9ukzR6_lfYx5joX41I_UEPBTyMyku2eFk87BUAJZZTUe25bmnC6yhO09noKhvYkZfsMtLfeY3luHTyWd88gRu62h5RHlss-JW50FqWM-vdTTG6gw",
    "e": "AQAB",
    "d": "FmmvWvWu7TTghuiaK12spvqUxGhatkhvvhUhKtTEuPuRx0LrO4tqRIAiTimYaIEUaF8xrSo_LmJ1Q8aOwR4W7v13x5tbioUBFScHVCJSpdlaA5UoD25dFCI1_VVZIaL6Ognw6CQUwMJTEaESsmGhCHf8LG6rkL4LJS6m0MAhGGvzEWUGSTWE3zK8qcZCnpZ73Aa0l4fq_d4D2U4k1rLrrjZF49SvOhcwaorSptsnPvsrzlMzcNv2bMTekHb-lPMWlbooJRu1OWAjM-6hQq1OrcgOD_EvaY1IUFUtFtK8TUJ_mxqdYg9zJLK5ywNmZAUWS7s3b-uM1sYOh3SuoIbnwQ",
    "p": "9Hp25bFhwLJIOA7wmEdEJ0aWVuwNshbCcio4Oo9IsluVvV9f12LUYWOE4JcKCo_eTnPcvWF3Pw9P8LNydGeq4hdzp8smZESgrtWP4t6Lpe12ssVd8cCqr_0ynnC6R7WUk9lQOranQwhIqYH4I1zx5D78QF0sLtp2DKXiNXBBcrk",
    "q": "uSJRgqfjBk3ZVb_A0auBTDArUOYetCuRjpgx4xnZzTxdd_fEG7XeRjFOmivThfcu5KMplM2PgN0EqxMIr7Gbqi4y9ivossgTLNO6Wre12PxdznP1B5M5g-1jkz3WBxfXeW1kO1FG7iyN3p8WPKsKVewE-VQzx8bX7Nn8pljDKRs",
    "dp": "n3w4jhUOYQesxy0v1RdApaKNtrydHp1sUc-rCMCqOvg2Eeji-_5T8AhdCapeeY9rBaDd0ol_ohqaGrrlonxyZLXJ1B9ZtzVx4TwednCZhzAHLA5G_8uhTdeOKv_89YTGHUE57mNzb-46gKHxvxgGENDp_A8MILCRLCUXEadeerk",
    "dq": "ImvQDePbIPvucbQCTLl_g8Pc-eCfSs5i9Mk1VU0kIrWbh0eozaIl3pUiUSXe4SSRMm9ntsP1b3cofApA7jGuiJioXv7Q-BSdBBOlrWJEzEA3zL_gifUEl5PWlLTFi3ISXQBKx4CYGIZuJjsb7lG6zTjhv9249ubwlJf_EoqkVos",
    "qi": "Vk8GYmY2egPuQMxqgntJX2SePvzf5QtLR2pqoDk2wEVNI50gzARCR_Qe7xzqe-QPDMprggN0o3uSwLU6SDelsa1TbfgQmHSq18rQgMrOk3zvAAZsGAP9Fll1V72zGj4TGvlwRr3RkUVhTQ5-yvTBgQa_QtHCT_fHQRYhSh9b8Fc"
}

單獨的公鑰格式如下：

{
    "kty": "RSA",
    "n": "jqMnbkOZfvwFQj1bvCu-TEKRT0at_pMXQ5WF_XVsZ4MaFgadSdzk7HydOWpVNPhhXzjY_Xsg_nS5rFPgYaSoKxhkKZrU6faSGI6qc_xChoUvAPgmkkQgXdwi3ceios4MfeK0Ktlxge-o71Ig5iGRMoe5q0oYdE6OxVD1JtJ564xgJKSwODLAt0AKGf5NVPLdu2LFMZcx3pf757fUEp0sZr0jl83nF7obUv1-hHdtwcGIFycrbwVHEPIHJl08uaQGwE-ve3-9ilCgw38-yl6w6adY2VIppxCq4qQdDBR2o2qFDBhJMDJyM_Lu2UF6t5ryLGjAEpKqbBlB7btnfbsgKQ",
    "e": "AQAB"
}

除此之外，密鑰對中返回的都是私鑰的部分。接下來，使用私鑰對對令牌進行簽名。

public Map<String, Object> jwtWithRs256(String sub, String[] aud, String jid) throws JoseException {
        JsonWebSignature jws = new JsonWebSignature();
        //設置Header
        jws.setHeader("alg", "RS256");
        jws.setHeader("typ", "JWT");
        jws.setHeader("kid", "ABCDEFG");
        //設置PayLoad
        JwtClaims jwtClaims = new JwtClaims();
        jwtClaims.setIssuer("rsa-me");
        jwtClaims.setSubject(sub);
        jwtClaims.setAudience(aud);
        jwtClaims.setExpirationTime(NumericDate.fromSeconds(2 * 60 * 60));
        jwtClaims.setNotBefore(NumericDate.now());
        jwtClaims.setIssuedAt(NumericDate.now());
        jwtClaims.setJwtId(jid);
        jws.setPayload(jwtClaims.toJson());
        //使用私鑰進行簽名
        RsaJsonWebKey jwk = RsaJwkGenerator.generateJwk(2048);
        jws.setKey(jwk.getPrivateKey());
        String jwt = jws.getCompactSerialization();
        HashMap<String, Object> result = new HashMap<>();
        result.put("jwt", jwt);
        return result;
    }

返回結果如下：

{
    "jwt": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IkFCQ0RFRkcifQ.eyJpc3MiOiJyc2EtbWUiLCJzdWIiOiJIZWxsb1dvcmxkIiwiYXVkIjoiaHR0cHM6Ly9yZXNvdXJjZWVuZHBvaW50LmNvbS91c2VySW5mbyIsImV4cCI6NzIwMCwibmJmIjoxNjM2NDQ0NzA4LCJpYXQiOjE2MzY0NDQ3MDgsImp0aSI6IkdISlNTSkpTRCJ9.WrUdvwcj8u09DOl3iMYT1Sc7ePEEB8vpbIZF31elJTu8mvr7HOWw1OgEVClvI9I82QyoqpgPR7_IWZ9r8p3o632W0C6jrYVE8Z_VRfHG-WB07yecOEUn730i3lHUC_wqZU3giUSdIBYiIrXinHHSSFuCzw3rPUwk0BougLza8b8uyrBRdtQ8toEjMmJtGF-l9wQayMVC6B8oAZKXkDt3CSIO1t_m9W6mGcFasH63P12TuGPZznrVcd41yn4hHHRMcrhVpEgs06ufFvdgmDRipuakec5DlV2ki8h0DYqwUUDlAZQtfdprC1QZVwA7tmeVYStnST1GQDy7hxrWbmqUyw"
}

將上面的jwt復制到jwt官網的工具中，就能看到如下結果，從結果來看，解析之后PayLoad中設置的信息與在代碼中設置的一模一樣，如果將上面獲取到的公鑰復制到公鑰輸入框中，就能看到簽名成功的提示，自測通過！

 

當客戶端接收到上面的token之后，向資源服務器發送請求：

curl --location --request GET 'https://resourceendpoint.com/userInfo' \
--header 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IkFCQ0RFRkcifQ.eyJpc3MiOiJyc2EtbWUiLCJzdWIiOiJIZWxsb1dvcmxkIiwiYXVkIjoiaHR0cHM6Ly9yZXNvdXJjZWVuZHBvaW50LmNvbS91c2VySW5mbyIsImV4cCI6NzIwMCwibmJmIjoxNjM2NDQ0NzA4LCJpYXQiOjE2MzY0NDQ3MDgsImp0aSI6IkdISlNTSkpTRCJ9.WrUdvwcj8u09DOl3iMYT1Sc7ePEEB8vpbIZF31elJTu8mvr7HOWw1OgEVClvI9I82QyoqpgPR7_IWZ9r8p3o632W0C6jrYVE8Z_VRfHG-WB07yecOEUn730i3lHUC_wqZU3giUSdIBYiIrXinHHSSFuCzw3rPUwk0BougLza8b8uyrBRdtQ8toEjMmJtGF-l9wQayMVC6B8oAZKXkDt3CSIO1t_m9W6mGcFasH63P12TuGPZznrVcd41yn4hHHRMcrhVpEgs06ufFvdgmDRipuakec5DlV2ki8h0DYqwUUDlAZQtfdprC1QZVwA7tmeVYStnST1GQDy7hxrWbmqUyw'

當資源服務器接收到請求之后，從header中解析中token，並使用公鑰驗證簽名：

　　　　//校驗簽名
        JsonWebSignature jsonWebSignature = new JsonWebSignature();
        jsonWebSignature.setKey(jwk.getPublicKey());
        jsonWebSignature.setCompactSerialization(jwt);
        boolean verify = jsonWebSignature.verifySignature();

當簽名驗證通過后，再根據客戶端請求返回資源即可。

3.3 其他的保護措施

 上面提到的HS256對稱簽名算法，是為令牌的內容計算256字節的散列，JOSE還定義了HS384和HS512等，它們計算出的散列值更長，從而生成更安全可靠的令牌；RS256非對稱簽名算法是對RAS簽名結果計算256字節的散列，同樣JOSE定義了RS384和RS512，除此之外，還要有PS256、PS384和PS512等，都是基於另一種RAS簽名和散列機制，從源代碼中可以看出jose4j庫中的簽名算法有以下這些：

除了簽名之外，JOSE還提供了一種叫做JWE的加密機制，包含集中不同的選項和算法。經過JWE加密的JWT不再只由3部分組成，而是由5部分組成，各個部分仍然使用Base64URL編碼，這是載荷變成了一個經過加密的對象，沒有正確的密鑰無法讀取其中的內容。

四、令牌內省

如果將所有的信息都放入令牌中也不是一種很好的辦法，因為令牌在網絡中傳輸的頻率很高，塞過多的信息只會增加網絡開銷，且一旦頒發很難撤銷，於是就有了令牌內省機制。

4.1 內省協議

 令牌內省協議定義了一種機制，讓受保護資源能夠主動向服務器查詢令牌狀態。由於令牌時授權服務器頒發，所以它知道令牌的所有細節。內省請求是發送給授權服務器內省端點的表單形式的HTTP請求，相當於受保護資源向授權服務器詢問：“有人向我出示了這個令牌，它是否有效？”受保護資源在請求過程中需要向授權服務器進行身份認證，以便讓授權服務器知道是誰在詢問，並可能根據詢問者的身份返回不同的響應。

資源服務器請求授權服務器的方式與客戶端請求授權服務器的方式相似，只不過授權服務器要給資源服務器提前分配好用戶身份認證的resoure_id和resource_secret.

4.2 構建內省端點

 為了支持令牌內省，授權服務器需要構建內省端點，為此需要完成以下步驟：

1、為資源服務器添加憑據，用戶進行身份認證

• resource_id：資源服務器唯一標識
• resource_secret：資源服務器密鑰

2、從資源服務器的請求中解析出其身份信息

3、授權服務器獲取到憑據之后，先對資源服務器進行身份認證，認證失敗直接返回錯誤信息，認證成功進行下一步

4、根據資源服務器傳過來的token查找令牌，如果令牌蹲在則將所有的信息添加到響應中，並以JSON的形式返回，如果沒有找到則返回無效通知。

4.3 發起令牌內省請求

 現在資源服務器就可以發起類似下面的內省請求了：

curl --location --request POST 'http://tokenendpoint.com/introspect' \
--header 'Content-Type: application/json' \
--header 'Authorization: basic BASE64(resourceId:resourceSecret)' \
--data-raw '{
    "token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IkFCQ0RFRkcifQ.eyJpc3MiOiJtZSIsInN1YiI6InpoYW5nc2FuIiwiYXVkIjoiaHR0cHM6Ly9yZXNvdXJjZWVuZHBvaW50LmNvbS91c2VySW5mbyIsImV4cCI6NzIwMCwibmJmIjoxNjM2NDQwNjU1LCJpYXQiOjE2MzY0NDA2NTUsImp0aSI6ImRmZGZkYWhrZmRoYXRlYXJlYXIifQ.2d4J1MIkT6AVzIoLzdEIUFnkpjisu_7tPfd_mCHvPg0"
}'

令牌內省結果：

{
    "active": true,
    "scope": "read",
    "client_id": "client_id",
    "username": "zhangsan",
    "iss": "rsa-me",
    "sub": "HelloWorld",
    "aud": "https://resourceendpoint.com/userInfo",
    "exp": 7200,
    "nbf": 1636445486,
    "iat": 1636445486
}

內省協議中規定內省響應結果是在JWT的基礎上增加了幾個聲明，最重要的是active，此聲明表示當前令牌在授權服務器上是否有效，且是唯一必須返回的聲明。

4.4 令牌內省與JWT結合

 一般情況下最好將JWT和令牌內省結合起來，JWT只需要攜帶基本信息，比如頒發者、有效期唯一標識等，用於初步檢查，檢查通過后執行令牌內省來獲取更詳細的令牌信息，比如提供授權的用戶、被頒發令牌的客戶端以及令牌所關聯的權限范圍等。

五、令牌撤回

 OAuth令牌撤銷規范，給客戶端提供了一種撤銷令牌的機制，使得客戶端在任何想要撤銷的地方，都能調用授權服務器提供的撤銷API。比如，客戶端可能是一個要從用戶設備上卸載的原生應用、或者客戶端給用戶一共了撤銷授權的操作界面、甚至在客戶端發現存在可疑行為並希望降低對已授權的資源的損害，只要撤回令牌，則授權服務器之前頒發的令牌將不能被使用。

5.1 令牌撤回協議

OAuth 令牌撤回協議是一個簡單的協議，它讓客戶端可以簡單地告訴授權服務器：“我持有這個令牌並希望你將它撤銷”，客戶端需要向撤銷端點發送附帶身份認證的HTTP POST請求，並將要撤回的令牌傳入請求體。

5.2 構建撤回端點

 在授權服務器上，接收到請求后首先獲取客戶端身份信息並對其進行身份認證，當客戶端身份認證通過之后，根據客戶端傳來的token查詢該令牌是否存在，如果存在且確認是頒發給該客戶端的令牌之后，將其從數據庫中移除即可。

5.3 發起令牌撤回請求

構建完之后，客戶端就能發起撤回請求，與令牌內省的請求相同，只不過是客戶端發起的，請求示例如下：

curl --location --request GET 'http://tokenendpoint.com/revoke' \
--header 'Content-Type: application/json' \
--header 'Authorization: basic BASE64(clientId:clientSecret)' \
--data-raw '{
    "token":"mCHvPg0"
}'

客戶端可以以同樣的方式撤回刷新令牌！

六、OAuth令牌的生命周期

關於令牌的生命周期，話不多說，一張圖說明一切

 

七、總結

OAuth令牌時OAuth系統中最重要的中心組件：

• OAuth令牌可以是任意格式，只要授權服務器和受保護資源能夠理解即可
• OAuth客戶端沒有必要理解令牌的格式
• JWT定義了一種在令牌中存放結構化信息的方式
• JOSE提供了對令牌內容進行加密保護的方法
• 令牌內省讓受保護資源可以在運行時查詢令牌狀態
• 令牌撤回讓客戶端可以向授權服務發送信號，將不再需要的令牌廢棄掉，結束令牌的生命周期。

至此，OAuth中令牌的介紹也差不多了，我想說，寫博客真不是一件簡單的事情，寫了一整天啊~~