u013905744的专栏

真实业务场景下的开放平台结构及实现文章目录需求：架构设计：API网关开发者中心授权中心控制后台实现：需求1：app登录需求2：小程序需求3：APP自身H5页面需求4-1：第三方H5页面，无server端需求4-2：第三方H5页面，有server端令牌有效期及scope的处理需求：APP支持多种登录方式包括：用户名和密码手机号加验证码其他渠道的第三方登录，如微信、支付宝等第三方登录支持微信小程序、支付宝小程序对受保护资源的请求支持APP自身H5页面对受保护资源的请求支持

oauth2.0协议解决什么问题？来解决资源拥有者如何委托第三方应用访问受保护资源的问题解决方案是什么？用令牌代替用户名和密码在OAuth 协议中，通过为每个第三方软件和每个用户的组合分别生成对受保护资源具有受限的访问权限的凭据，也就是访问令牌，来代替之前的用户名和密码。而生成访问令牌之前的登录操作，又是在用户跟平台之间进行的，第三方软件根本无从得知用户的任何信息。oauth2.0中的4种角色在OAuth 2.0的体系里面有4种角色，按照官方的称呼它们分别是资源拥有者、客户端（第三方软件）、授权

受保护资源最终指的还是Web API，比如说，访问头像的API、访问昵称的API。对应到我们的打单软件中，受保护资源就是订单查询API、批量查询API等。首先要做的是检查令牌的合法性，之后确定权限范围。提供一个统一的网关层来处理校验。文章目录1. 检查令牌的合法性2. 确定权限范围权限维度1：不同的权限对应不同的操作权限维度2：不同的权限对应不同的数据权限维度3：不同的用户对应不同的数据3. 提供一个统一的网关层来集中处理校验1. 检查令牌的合法性受保护资源来调用授权服务提供的检验令牌的服务方案有

如果要基于开放平台构建一个第三方软件的应用，第三方软件的研发人员应该做哪些工作？要到开放平台申请注册为开发者，在成为开发者以后再创建一个应用，之后就开始开发了开发第三方软件应用的过程中，第三方软件的研发人员需要重点关注哪些内容呢？这些内容包括4部分，分别是：注册信息、引导授权、使用访问令牌、使用刷新令牌1. 注册信息第三方软件软件需要先拥有自己的app_id和app_serect等信息，同时还要填写自己的回调地址redirect_uri、申请权限等信息。2. 引导授权比如，用户要使用第三方软件

授权这个大动作的前提，肯定是第三方软件要去平台那里“备案”，也就是注册。注册完后，开放平台就会给第三方软件app_id和app_secret等信息，以方便后面授权时的各种身份校验。同时，注册的时候，第三方软件也会请求受保护资源的可访问范围。授权服务可以说是整个OAuth 2.0体系中的 “灵魂” 组件，任何一种许可类型都离不开它的支持，它也是最复杂的组件。它将复杂性尽可能地“揽在了自己身上”，才使得第三方软件接入OAuth 2.0的时候更加便捷。授权服务器组成提供4个端点 endpoint

在学习oauth2.0协议的时候，对于刷新令牌refresh token感觉很困惑。主要是为啥需要刷新令牌，以及刷新令牌是如何工作的，技术细节是啥？比如通过refresh token可以让access token永久不过期吗？下面就针对这两个问题进行分析。为什么需要刷新令牌如果access token超时时间很长，比如14条，由于第三方软件获取受保护资源都要带着access token，这样access token的攻击面就比较大。如果access token超时时间很短，比如1个小时，那其超时之后

什么是SSO？web登录的本质是什么？如何增加状态/会话单个系统的登录扩展到多个系统，就是SSO方案1：共享cookie，后台共享sessionspring session项目就是共享session，共享session放到redis中Session Cookie要种在Web应用的根域上，也就是说不同Web应用的根域必须相同，否则会有跨域问题。方案2：共享cookie，后台不共享session签名的方式来校验方案3：使用独立的认证中心CAS(central authen

场景在前后端分离的项目中，一般后端返回给前端的格式是一个固定的json格式。在这个前提下，spring security oauth 生成access token的请求/auth/token的返回内容就需要自定义原返回值我们希望使用我们自己固定的json格式需求我们的BaseResponse类public class BaseResponse { pri...