OAuth20原理图解第三方网站为什么可以使用微信登录( 二 ) _为什么软件可以用微信登录

(2) code只能使用一次，使用完成后会被删除，需要重新按照授权流程获取
3 JWT3.1 发现问题在第二章节详细分析了OAuth2.0协议，在实现流程章节分析了创建应用、授权流程、获取信息三个流程，我们发现一个问题：在流程图3.3步骤资源服务器需要远程调用授权服务器check_token端点校验令牌是否有效，这样比较消耗性能。
如果资源服务器和授权服务器约定一个密钥对，授权服务器用秘钥加密令牌，当资源服务器接收到令牌时进行解密直接对令牌进行校验，这样可以节省远程交互。
3.2 进行比较JSON Web Token（JWT）可以解决上述之问题，作为一个开放标准（RFC 7519）定义了一种紧凑的自包含方式，用于作为JSON对象在各方之间安全地传输信息。
3.2.1 普通令牌{"access_token": "1fa67a8b-12a9-4862-b9ef-983d6554cd19","token_type": "bearer","refresh_token": "e0a417a9-33cc-4034-84c1-d09dc80a8c31","expires_in": 49999,"scope": "test"}3.2.2 JWT{"access_token": "aaa.bbb.ccc","token_type": "bearer","refresh_token": "ddd.eee.fff","expires_in": 49999,"scope": "test"}JWT分为头部、有效载荷和签名三个部分。头部包含签名算法以及token类型。有效载荷包含真正业务信息，例如用户ID、姓名、邮箱、权限信息。头部和有效载荷任何人都可以读出来，所以需要用签名防止篡改：头部和有效载荷分别进行Base64编码，编码后用 . 连接组成新字符串，再使用头部声明算法进行签名。
JWT = Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)"."base64UrlEncode(payload),secret)JWT令牌内容：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjpbeyJuYW1lIjoidGVzdF9uYW1lIn0seyJlbWFpbCI6InRlc3RfZW1haWwifV0sImlhdCI6MTY0NzE4MTc0NywiZXhwIjoxNjQ3MzU5OTk5LCJhdWQiOiJ0ZXN0MiIsImlzcyI6InRlc3QxIiwic3ViIjoidGVzdDMifQ.k0dknW7ff4KyMIMbBmnZtI3nf2lWN9KVKQrGwcyOGYIJWT解码内容：
{"header":{"alg":"HS256","typ":"JWT"},"payload":{"data":[{"name":"test_name"},{"email":"test_email"}],"iat":1647181747,// Issued At 签发时间"exp":1647359999,// Expiration 过期时间"aud":"test2",// Audience 受众"iss":"test1",// Issuer 签发人"sub":"test3"// Subject 主题}}3.3 整体流程

文章插图
4 OpenID Connect4.1 授权与认证在第二章节详细分析了OAuth2.0协议，我们还发现一个问题：客户端在获取到令牌之后，还需要调用资源服务器接口获取用户信息，有没有一种协议可以在返回令牌时同时将用户是谁返回？
我们首先对比一组概念：授权与认证。授权关注通信实体具有什么权限，认证关注通信实体是谁。OAuth2.0只有授权流程，返回令牌之后授权流程已经完成，OpenID Connect在此基础上进行了扩展，客户端能够通过认证识别用户。
4.2 三种角色OpenID Connect协议定义三种角色：
最终用户（End User）依赖方（Relying Party）身份认证提供商（Identity Provider）三种角色交互流程：

文章插图
本文场景对应三种角色：

文章插图
4.3 进行比较4.3.1 id_tokenOIDC标准协议新增id_token字段，这个字段符合JWT标准格式，那么为什么不与第三章节采用相同方式，在access_token包含有效负载信息而是新增id_token字段？
因为即使access_token可以加入用户信息并且通过加签防篡改，但是用户每次请求都需要携带access_token，增加了带宽和信息泄露风险。
{"access_token": "1fa67a8b-12a9-4862-b9ef-983d6554cd19","token_type": "bearer","refresh_token": "e0a417a9-33cc-4034-84c1-d09dc80a8c31","expires_in":3599,"id_token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjpbeyJuYW1lIjoidGVzdF9uYW1lIn0seyJlbWFpbCI6InRlc3RfZW1haWwifV0sImlhdCI6MTY0NzE4MTc0NywiZXhwIjoxNjQ3MzU5OTk5LCJhdWQiOiJ0ZXN0MiIsImlzcyI6InRlc3QxIiwic3ViIjoidGVzdDMifQ.k0dknW7ff4KyMIMbBmnZtI3nf2lWN9KVKQrGwcyOGYI"}4.3.2 userinfoOIDC标准协议要求提供了一个/userinfo端点，可以通过传入access_token调用获取用户信息，那么既然id_token已经包含了用户信息，为什么还要提供这个端点？