OAuth 2.0 OAuth令牌 4

一.OAuth 令牌是什么

　　令牌表示的是授权行为的结果：一个令牌元组，包括资源拥有者、客户端、授权服务器、受保护的资源、权限范围以及其他与授权决策有关的信息。授权服务器要知道如何生成令牌来颁发给客户端，资源服务器要知道如何识别并验证客户端发送过来的令牌。

　　令牌可以具有有效期，可以支持撤回。令牌可以代表特定的用户或者系统中所有用户，也可以不代表任何用户。

　　令牌可以具有内部结构，可以是随机的无意义字符串，也可以被加密保护。

　　创建随机的无意义字符串令牌都是由字母和数字组成的随机字符串，在网络上的形式如：sdfsfppxpos332fsd3sf33afmhbyhhj。 授权服务器生成令牌之后，会将令牌值存储在磁盘上的共享数据库中如mysql。当受保护资源从客户端收到令牌之后，它会在同一个数据库中查找令牌值，以确定令牌有效。这种令牌不携带任何信息，只是充当数据库查询的检索值。这种创建和管理令牌的方法非常有效且常见，而且优势是保护令牌本身短小。如果授权服务器和受保护资源间不能共享数据库，这方法是不行的。特别是一个授权服务器需要保护下游的多个资源服务器情况下，如何解决？ 两种常见的方式是结构化令牌和令牌内省。

二.结构化令牌JWT

　　如果不向共享数据库查询，需要将所有必要的信息放在令牌内部，这种方式使授权服务器可以通过令牌本身间接地与受保护资源沟通，而不需要调用任何网络API。

　　通过这种方式，授权服务器可以将受保护资源需要知道的信息全部打包，比如令牌的过期时间戳以及授权用户是谁等，这些信息都会被发送给客户端，但客户端不需要关心， 客户端发送给受保护资源后，受保护资源需要理解令牌，并解析令牌内包含的信息，然后基于这些信息做出授权决策。

　　1.jwt的结构

　　　　为了构建这样的令牌，Json web 令牌格式也叫jwt, 它提供了一种令牌中携带令牌的简单方法。jwt的核心是一个json对象封装在网络上转输的格式，jwt是简单的形式是一个未签名的令牌。

　　　　JWT 由三部分组成，Header、Payload、Signature。它们之间用 圆点. 连接，并使用 Base64 编码。采用Baseb4URL编码方案是可以让jwt安全地出现在任何环节而无需额外编码处理。　

　　　　第一部分HEADER 是jwt的头部如下：

{
    "alg": "RS256",   #签名类型， none代理令牌未签名
    "typ": "JWT",   #jwt结构的令牌
    "kid": "vv9_FSBQ--STeR6YXOdxqPq5WRUDr1jNeFRuQC6DKoY"  #kid是指标识一个秘钥ID，可选
}

　　　　第二部分PAYLOAD是令牌载荷，代表一组声明

{
    "exp": 1675390066,   #令牌的过期时间戳，该声明是一个整数，转为时间为：2023-2-3 10:7:46 
    "iat": 1675389466,   #令牌的颁发时间戳
    "jti": "1cc8877a-ab19-4965-be94-47b37aec68b8", #令牌的唯一标识符，该声明的值在所有令牌中都是唯一的
    "iss": "https://keycloak.mogul-tech.com/realms/ebs", #令牌颁发者，表过令牌是由谁创建的，是一个授权服务器的URL
    "aud": "account", #该令牌的接收者，也叫受众
    "sub": "e7d68aa1-ad6e-48aa-a55d-9abd88a6ec99", #令牌主体，表示该令牌是关于谁的，在很多OAuth部署中会将它设为资源拥有者的唯一标识符，也就是用户ID, 这里也是指用户ID
    "typ": "Bearer", #认证方式
    "azp": "vendorotthapi-webapi",
    "acr": "1",
    "realm_access": {
        "roles": ["default-roles-ebs", "offline_access", "uma_authorization"]
    },
    "resource_access": {
        "account": {
            "roles": ["manage-account", "manage-account-links", "view-profile"]
        }
    },
    "scope": "write_update profile email",  #权限范围
    "email_verified": false,
    "clientId": "vendorotthapi-webapi",  #客户端ID
    "clientHost": "116.30.223.145",
    "name": "ebs",  #用户名字
    "preferred_username": "service-account-vendorotthapi-webapi",
    "given_name": "ebs",
    "clientAddress": "116.30.223.145",
    "family_name": ""
}

　　2.令牌的加密保护 JOSE

　　　　如果未签名的令牌则是明文的，对于客户端来说，很容易就能在向受保护资源出示令牌之前篡改令牌内容。客户端甚至可以不与授权服务器通信的情况下就自行伪造一个令牌出来，而资源服务器还是会天真地接受并处理。

　　　　JOSE：签名和加密标准，这套规范以json为基础数据模型，提供了签名(JSON Web签名或称jws)、加密(JSON Web加密或称jwe)以及秘钥存储格式(JSON Web秘钥或称jwk)的标准。

　　　　JOSE的知识点太多，不多介绍，着眼于它的两项内容：使用HMAC签名方案的对称签名和验证，以及使用RSA签名方案的非对称签名和验证。

　　　　1)使用HS256的对称签名

　　　　2)使用RS256的非对称签名

三.令牌内省