OAuth Flow和选型
四种oath2.0授权类型（flows）
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。
• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

一、授权码模式
授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
授权码模式是最复杂、最安全的模式，日常开发最常用的。
- 通过前端渠道客户获取授权码
- 通过后端渠道,客户使用authorization code去交换access Token和可选的refresh token
- 假定资源拥有者和客户在不同的设备.上
- 最安全的流程,因为令牌不会传递经过user-agent

二、简化模式
简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
- 适用于公开的浏览器单页应用
- Access Token直接从授权服务器返回(只有前端渠道)
- 不支持refresh tokens
- 假定资源所有者和公开客户应用在同一个设备上
- 最容易受安全攻击

三、密码模式
密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。
在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
- 使用用户名密码登录的应用，例如桌面App
- 使用用户名/密码作为授权方式从授权服务器上获取access token
- 一般不支持refresh tokens
- 假定资源拥有者和公开客户在相同设备上

四、客户端模式
客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
- 适用于服务器间通信场景,机密客户代表它自己或者一个用户
- 只有后端渠道，使用客户凭证获取一个access token
- 因为客户凭证可以使用对称或者非对称加密，该方式支持共享密码或者证书

Outh2.0模式如何选型