Oauth 2.0的几种授权模式及应用场景

Oauth 2.0

2012年10月， OAuth 2.0协议正式发布为 RFC 6749。现在 百度开放平台， 腾讯开放平台等大部分的开放平台都是使用的 OAuth 2.0协议作为支撑。

概述

OAuth是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。

在OAuth 2.0的认证和授权的过程中主要包括以下角色定义：

• Resource owner： 资源所有者（通常指用户或者提供资源服务的平台）
• Resource server：资源服务器（托管受保护资源的服务器）
• Client：客户端（浏览器、APP）
• Authorization server：授权服务器（颁发访问令牌、验证令牌、刷新令牌）

交互过程

OAuth 在 "客户端" 与 "服务提供商" 之间，设置了一个授权层（authorization layer）。"客户端" 不能直接登录 "服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端" 登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。"客户端" 登录授权层以后，"服务提供商" 根据令牌的权限范围和有效期，向 "客户端" 开放用户储存的资料。

以下为QQ的授权页面，采用的是授权码模式

客户端授权模式

• implicit：简化模式，（不安全，适用于纯静态页面应用）
• authorization code：授权码模式（功能最完整、流程最严密的授权模式，通常使用在公网的开放平台中）
• resource owner password credentials：密码模式（一般在内部系统中使用，调用者是以用户为单位。）
• client credentials：客户端模式（一般在内部系统之间的API调用。两个平台之间调用。调用者是以平台为单位。）

简化模式

简化模式适用于纯静态页面应用。该模式下， access_token 容易泄露且不可刷新

1. 用户请求网站，如：www.tangyuewei.com
2. 重定向到一个授权页面
3. 用户同意授权
4. 重定向到网站，并带上access_token如：www.tangyuewei.com?access_token=123
5. 获取到资源服务器的资源

授权码模式

适用于有自己的服务器的应用，它是一个一次性的临时凭证，用来换取 access_token 和 refresh_token。一旦换取成功， code 立即作废，不能再使用第二次。

1. 用户请求网站，如：www.tangyuewei.com
2. 重定向到一个授权页面
3. 用户同意授权
4. 重定向到应用的一个回调地址，如：www.tangyuewei.com/recieve_token?code=123
5. 用code换取access_token和refresh_token

密码模式

用户向客户端提供自己的用户名和密码，向 "服务商提供商" 换取 access_token 。

客户端模式

如第三方，或者调用者是一个后端的模块，没有用户界面的时候，可以使用客户端模式。鉴权服务器直接对客户端进行身份验证，验证通过后，返回 token。

接入公司内部系统

• 后台管理系统
• 前台业务系统

后台管理系统

后台系统之间资源互相访问，如：日志模块，发邮件模块，发短信模块等（平台资源）。

需要引用相关模块的系统可采用客户端模式授权

前台业务系统

前台系统之间资源互相访问，如：用户信息，模块等（用户资源）。

需要引用相关模块的系统可采用密码模式授权

综合建议

综合上述模式及认证流程，个人觉得以下场景可以考虑引入Oauth 2.0认证：

1. 系统敏感资源服务进行安全认证及资源保护工作
2. 多个服务的统一登录认证中心、内部系统之间受保护资源请求
3. 将受保护的用户资源授权给第三方信任用户
4. 以后要做开发平台类似百度开放平台，腾讯开放平台