oauth2

1.什么是OAuth2
OAuth 2.0是用于授权的行业标准协议。OAuth 2.0致力于简化客户端开发人员的工作，同时为Web应用程序，桌面应用程序，移动电话和客厅设备提供特定的授权流程。
是开放授权的一个标准，允许用户授权B应用不提供帐号密码的方式去访问该用户在A应用服务器上的某些特定资源。
OAuth2是用于REST/APIs的代理授权框架(delegated authorization framework)
是基于令牌Token的授权,在无需暴露用户密码的情况下,是应用能获取对用户数据有限访问权限
解耦认证和授权
标准安全框架,支持多种用例场景
服务器端WebApp
浏览器单页SAP
无线/原生App
服务器对服务器之间
2.应用场景
第三方应用授权登录：在APP或者网页接入一些第三方应用时，时长会需要用户登录另一个合作平台，比如QQ，微博，微信的授权登录。

原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、请求后台数据。

前后端分离单页面应用（spa）：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证，比如使用vue、react后者h5开发的app。
OAuth2 解决的问题域

1、开放系统间授权
社交联合登录
开放API平台
2、现代微服务安全
单页浏览器App(HTML5/JS/无状态)
无线原生App
服务器端WebApp
微服务和API间调用
3、企业内部应用认证授权(IAM/SSO)
整体的流程就是:
客户应用向授权服务器请求Sccess Token —> 授权服务器向用户征询意见,是否将权限授予客户应用 —> 用户同意 —> 授权服务器生成颁发Access Token给客户应用 —> 客户应用请求资源服务器 —> 资源服务器验证客户应用的Access Token —> 验证通过,返回数据.

涉及到三个角色:

客户应用(请求资源方)
授权服务器(生成Access Token并颁发Access Token)
资源服务器(验证Access Token,返回资源)
OAuth2的优点和缺点
优点:

OAuth2.0比1.0更容易实现
更安全,客户端不接触用户密码,服务器端更易于集中保护
广泛传播并被持续使用
短寿命和封装的token
资源服务器和授权服务器解耦
集中式授权,简化客户端
HTTP/JSON友好,易于请求和传递token
考虑多种客户端架构场景
客户可以具有有不同的信任级别
缺点:

协议框架太宽泛,造成各种实现的兼容性和相互操作性差
和OAuth1.0不兼容
OAuth2.0不是一个认证协议(是授权协议),OAuth2.0本身并不能告诉你任何用户信息.
OAuth2.0主要角色
资源拥有着(RO): 资源的拥有人,想要分享某些资源给第三方应用
客户应用: 通常是一个Web或者无线应用,需要访问用户的受保护资源
资源服务器: Web站点或者Web service API,用户的受保护数据存在此处
授权服务器:客户应用成功认证并获得授权之后,向客户应用颁发访问令牌Access Token
OAuth术语
客户凭证: 客户的clientId和密码用于认证客户
令牌: 授权服务器在接收到客户请求后,颁发的访问令牌
作用域: 客户请求访问令牌时,由资源拥有者额外指定的细分权限(permission)
OAuth2的令牌类型
授权码(Authorization Code Token): 仅用于授权码授权类型,用于交换获取访问令牌和刷新令牌
刷新令牌(Refresh Token): 用于去授权服务器获取一个新的访问令牌
访问令牌(Access Token): 用于去代表一个用户或服务直接去访问受保护的资源.
Bearer Token: 不管谁拿到Token,都可以访问资源,像现钞
Proof of Possession(PoP Token): 可以校验client是否对Token有名确的拥有权
访问令牌是最重要的.

OAuth2.0误解
OAuth并没有支持HTTP以外的协议
OAuth并不是一个认证协议
OAuth并没有定义授权处理机制
OAuth并没有定义token格式
OAuth2.0并没有定义加密算法
OAuth2.0并不是单个协议
OAuth2.0仅是授权框架,仅用于授权处理
OAuth的本质就是如何获取token和如何使用token.
OAuth是一种在系统间的代理授权协议(delegation authorization)
OAuth提供一个宽泛的协议框架,具体安全场景需要定制
OAuth使用代理协议的方式解决密码共享反模式问题
四中OAuth2.0授权类型(Flows)

四种模式详情可参看以下：OAuth 2.0 的四种方式