在OAuth协议流程中有几个关键角色:
- Resource server（资源服务器）
通过OAuth保护，储存用户资源的服务器，也可认为是功能API应用。第一方。 - Resource owner （资源拥有者）
一个应用的用户，资源拥有者有访问他们在资源服务器上储存的数据的权限。第二方。 - Client （客户端）
一个代替用户身份访问资源服务器的应用，需要得到用户的授权。第三方。 - Authorization server （授权服务器）
授权服务器从资源拥有着那得到同意权限，颁发access tokens，使客户端有访问资源服务器中资源的权限。
后台通道和前台通道
在Client （客户端）和 Authorization server （授权服务器）之前的交互通道可分为 后台通道（back-channel）和前台通道(front-channel)。后台通道（back-channel）是客户端服务器和授权服务器之间的通信，比较安全，不容易被监听。前台通道(front-channel)是客户端浏览器或移动端和授权服务器之间的通信，容易被监听，安全系数较低。
比较经典OAuth2.0授权流程 "authorization code grant" 就是采用 后台通道（back-channel）+ 前台通道(front-channel) 的方式，这样灵活的解决了前台用户的授权交互，又能在请求 access_token的时候绕开了用户，直接采用 后台通道（back-channel），保证了access_token的安全。
有些嵌入的应用（javascript,移动APP等）没有分离的前后端，也就是没有办法启用 后台通道（back-channel） ，只能采用简化的"implicit grant" 授权流程，客户端只能采用前台通道(front-channel)和授权服务器进行交互。
OAuth 2.0 流程类型
- Authorization code (前台通道 + 后台通道)
- Implicit （前台通道）
- Client credential (后台通道)
- Resource ower password credentials (后台通道)
Authorization code 流程
Resource owner （资源拥有者）首先会被重定向到Authorization server （授权服务器），Resource owner （资源拥有者）成功激活会话后，也就是登录成功后，提示其授权Client （客户端）对数据的检索请求，授权成功后，Resource owner （资源拥有者）又会被转回Client （客户端），并在URL上携带Authorization code：
由于 code是采用查询字符串的形式进行传递的，浏览器会将这个参数发送到客户端后台。客户端后台在使用code 向Authorization server （授权服务器）请求access_token。客户端之后再调用API时，都需要在请求头中携带 access_token。
什么时候需要采用Authorization code 流程
Authorization code 流程应在以下场景使用：
- 需要长时间对API进行检索
- 客户端有Web后台
- 对API的保护级别非常高，不能向浏览器泄漏access_token
Implicit 流程
基于浏览器的客户端 web 应用程序的隐式授予流程非常简单。在此流程中, 在用户授予请求的授权后, 访问令牌（access_token）将立即返回到应用程序,而无需中间授权代码（Authorization code）。
什么时候需要采用Implicit 流程
Implicit 流程应在以下场景使用：
- 仅仅需要对数据进行临时检索
- 客户端运行在浏览器中（javascript,Flash）。
- 对access_token是否泄漏不太敏感
Client credential 流程
采用Client Credentials方式，即应用公钥、密钥方式获取Access Token，适用于任何类型应用，但通过它所获取的Access Token只能用于访问与用户无关的Open API，并且需要开发者提前向开放平台申请，成功对接后方能使用。认证服务器不提供像用户数据这样的重要资源，仅仅是有限的只读资源或者一些开放的 API。例如使用了第三方的静态文件服务，如Google Storage或Amazon S3。这样，你的应用需要通过外部API调用并以应用本身而不是单个用户的身份来读取或修改这些资源。
Resource Owner Password Credentials流程
Resource Owner Password Credentials Grant模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。
在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
参考：
