OAuth2.0协议
2025-04-11 17:53:06 1 举报AI智能生成
OAuth2.0协议
作者其他创作
大纲/内容
角色
资源拥有者【用户】
客户端（或第三方平台）
授权服务
受保护的资源
问题简析
1、认证流程不使用 授权码直接使用 access_token可以吗？
如果值使用access_token那么只发生一次重定向（即三方平台引导用户重定向到授权服务页面），那么授权服务直接生成 access_token之后可以下发到浏览器或者三方服务器（即三方服务器的前端和后端），但是认证码是安全性要求不高的，而access_token是安全性要求比较高的，最好不要下发到前端。 那么下发到三方服务器端后，就断开了与用户的联系，用户一直停留在授权页面。 所以增加额外的授权码流程，增加一次重定向是为了增加安全性和用户体验。
2、认证流程一点要浏览器参与吗？
浏览器只是初期所有的服务基本都是浏览器实现的，而 Oauth2.0协议只是一种思想或者协议，比如微信的授权服务，就是使用完整的 OAuth2.0 授权码许可流程实现，小程序使用微信的sdk内部发起了重定向操作。或者可以理解，浏览器只是作为三方的前端而已，前端可以使用浏览器也可以不是浏览器。
3、为什么需要刷新token？
前提是 grant_type为 授权码许可类型 或 资源拥有者凭据许可类型。 不能token失效时间为 30分钟，那么用户使用三方软件时，每三十分钟就要去用户去登录一次并进行授权操作，而是可以进行续租，不用用户参与增加用户体验。
Oauth2.0协议类型
授权码许可类型【Authorization Code】
grant_type=
资源拥有者许可类型【Resource Owner Password Credentials】
grant_type=password
客户端许可类型【Client Credentials】
grant_type=
隐式许可类型【Implicit】
grant_type=
授权码许可流程解析
授权码许可流程 概览图
细节说明
1、三方平台需要代表用户去 开放平台获取资源前需要去 授权服务或者开放平台先注册获取用 app_id和app_secret
2、第一次重定向到授权服务，下发授权页面供用户选择
验证三方服务的备案资格即 app_id和app_secret
资源scope展示给用户，让用户选择授权scope（比如订单是当天的资格还是最近一个月的订单数据；
比如微信三方登录让用户选择自己授权是否授权 昵称、头像、性别、地理位置等信息）。
比如微信三方登录让用户选择自己授权是否授权 昵称、头像、性别、地理位置等信息）。
3、用户提交授权提交过程
验证三方服务的备案资格即 app_id和app_secret
验证回调地址是否正确（即第二次重定向的地址）
用户授权的权限范围验证
处理请求生成 授权码 Code
OAuth规范建议授权码有效期为 10分钟，并且只能使用一次。一般生成环境建议是 5分钟
生成的授权码与已经授权的权限范围 scope进行绑定存储
再重定向到第三方软件
4、颁发access_token
验证第三方软件是否存在
验证授权码code值的合法性，验证后应该马上删除授权码值，防止其他恶意访问
生成access_token 和 refresh_token
token要求符合三个原则：唯一性、不连续性、不可猜性
token要与 哪个第三方服务、哪个用户、哪个权限范围 进行绑定存储（redis或者数据库或者jwt）
token要设置一个过期时间 expires_in，比如 30分钟
5、下发refresh_token和验证
如果【grant_type】授权码许可类型 或 资源拥有者凭据许可类型，那么下发 acess_token时需要下发 refresh_token， 并且提供 refresh的接口
refresh_token验证 接口， 接受刷新令牌请求并验证基本信息，刷新时必须废弃原来的刷新令牌
刷新令牌可以在原来的令牌基础上进行续租，即调整过期时间，但是一般是建议重写生成一个。 否则客户端一直定时刷新token， 那么一直是同一个token，安全性太低。
PKCE协议: 但是一般建议都有服务端，所以不具体研究PKCE了，
本质就是使用算法，基于挑战编码和验证码，来保证流程
本质就是使用算法，基于挑战编码和验证码，来保证流程
当开发App并且没有服务端【或者单页SPA】时，Oauth2.0协议中的 app_id和app_secret存储在哪里呢，放到App端太不安全了。那么有没有一种不使用app_id、app_secret的就可以执行Oauth2.0协议的流程呢？ PKCE协议
APP端的两种场景
OAuth2.0协议出现是2012年，PKCE协议是 2015年出现的，主要就是为了解决互联网爆发式增长增加的各种不同场景问题。
OAuth2.0规定了两种 code_challenge_method 加密算法
plain：code_verifier值和code_chanllenge值相同
S256： code_challenge = base64(SHA256(ASCII(code_verifier)))；
PKCE协议允许 客户端自己生成一个随机的 43-128位的字符串作为 code_verifier,
再根据 挑战码的算法 计算出一个挑战码。那么在获取授权码和获取令牌的两个步骤：
再根据 挑战码的算法 计算出一个挑战码。那么在获取授权码和获取令牌的两个步骤：
获取授权码阶段：传入 code_challenge_method和code_challenge值告授权服务
获取令牌阶段：传入 code_verifier， 此时授权服务就可以使用 code_verifier通过code_challenge_method计算出 code_challenge的值进行比较了。
阿里、微信、美团的接入文档
微信
https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html
支付宝
https://opendocs.alipay.com/isv/10467/xldcyq
美团
子主题
收藏
0 条评论
下一页
