OAuth2 原理概览

前言

OAuth2应用广泛，网上也不乏优秀的参考文章，想要快速了解OAuth2的朋友，可以参考阮一峰-OAuth2.0的一个简单解释。本文仅为个人理解，将OAuth的概念原理进行整理归纳，在查阅资料时，发现阮一峰老师的OAuth专题博文已将这一主题解析得相当透彻，因此下文不再赘述，直接引用作为内容填充，请阅读本文的读者务必点开引用链接一起阅读。

一、OAuth标准

OAuth2是关于授权认证的一种开放标准RFC6749，它允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。

1.1 角色

它引入了授权层，定义了4种角色。

• Resource Own 资源所有者：能够授予对受保护资源的访问权限的实体。

• Resource Server 资源服务器：托管受保护资源的服务器。

• Client 客户端：发出受保护资源请求的应用程序。

• Authorization Server 授权服务器：验证资源所有者身份成功后颁发令牌的服务器。

1.2 整体过程

1. 客户端向资源所有者请求授权

2. 资源所有者同意给客户端授权

3. 客户端携带 2 得到的授权向授权服务器申请令牌

4. 授权服务器对客户端进行验证，确认后并颁发令牌

5. 客户端携带 4 得到的令牌向资源服务器请求被保护的资源

6. 资源服务器验证令牌成功后，响应请求

oauth2_flow.png

二、客户端授权模式

OAuth2 支持4种授权方式，适用于不同场景。阮一峰-OAuth2的四种方式，讲的很细致很好理解，下面将这四种模式进行简单总结区分。

• Authorization Code 授权码模式

  最安全最常用，比如使用微信登录第三方应用就是使用了授权码模式，具体可以了解移动应用微信开发指南。用于获取令牌和刷新令牌，适用于前后端合作的情况。

• Implicit 简化模式

  因没有获取授权码这一过程，直接获取令牌，又称隐藏式授权码模式。安全性不高，不能获取刷新令牌，适用于纯前端的应用。

• Resource Owner Password Credentials 密码模式

  直接使用 resource own 的用户名密码申请令牌，安全性不高，必须是用户高度信任的应用。

• Client Credentials 客户端凭证模式

  直接通过 client_id 和 client_secret 获取令牌，不带用户信息，获取的是应用级的令牌。

参考

RFC6749

阮一峰-OAuth2的四种方式

阮一峰-OAuth2.0的一个简单解释

移动应用微信开发指南