随着系统的业务的扩展和互联网更多的相互融合、应用，系统也由原来的单体应用转变成微服务应用，以及与第三方系统间进行联合登录，系统服务将面临更多的安全问题， 如何授权、鉴权将是需要解决的问题。
一、业内的应用较多的OAuth2，什么是OAuth2？
- 用于REST/APIs的代理授权框架（delegated authorization framework）；
- 基于令牌Token的授权，在无需暴露用户密码的情况下，使应用有获取用户资源的权限；
- 解耦认证和授权；
- 是标准的安全框架，支持多种用例场景；例如：服务器端、浏览器单页、APP、第三方服务的授权；
- 注意事项：
- OAuth2是仅是授权框架、仅用于授权代理；
- 其并未定义授权处理机制；
- 其并没有定义token格式；
- 其并未定义加密方法；
二、其主要可解决以下的问题和应用场景。
- 开发系统间的授权
- 社交联合登录：使用QQ/微信/淘宝/支付宝等账户，登录第三方应用的系统；用户省去了注册信息的过程，第三方系统也从授权方拿到了部分用户信息；
- 开发API平台：功能性系统在扩展到一定规模后，将功能以API的形式开放出去，通过授权方式，允许第三方调用其API；
- 二、微服务安全
- 应用端接入授权，例如：H5、小程序、APP、服务端API间调动等等；
三、OAuth2应用场景图示：
上述应用场景可以以QQ授权登录OSCHINA为案例进行分析：
- 用户在OSCHINA端点击QQ授权登录，将授权请求发至QQ授权服务器；
- QQ授权服务器弹出QQ授权登录界面，提示用户使用扫码或者用户名密码登录；
- 用户扫码或者使用用户名密码登录表示同意授权，并选择OSCHINA可以使用QQ头像；
- QQ授权服务器给与OSCHINAAccess Token；
- OSCHINA使用获取的Access Token去QQ资源服务器获取QQ头像；
- QQ资源服务器通过Access Token校验，通过后给与QQ头像图片资源；
四、OAuth2四种典型模式
- 授权码模式：通过前端渠道获取授权码，使用授权码，在后端渠道去交换Access Token和Refresh Token(可选)。其为最安全的流程，因为令牌不经过客户端应用；
- 简化模式：Access Token直接从授权服务器返回给前端渠道，不支持Refresh Token，最容易受到攻击；
- 密码模式：使用用户名密码作为授权方式，获取Access Token,一般不支持Refresh Token;
- 客户端模式：适用于服务器间的通信场景，在后端渠道直接获取一个Access Token;
五、OAuth2授权类型选择
六、授权服务器架构基本端点
- 授权端点（Authorize Endpoint）
- 获取Token端点（Token Endpoint）
- 校验Token端点（Introspection Endpoint）
- 调销端点（revocation Endpoint）
来源：oschina
链接：https://my.oschina.net/zxh821215/blog/3189730