欢迎使用通行证

前言

OAuth 2.0 全称是 Open Authorization 2.0, 是用于授权(authorization)的行业标准协议。OAuth 2.0 专注于客户端开发人员的简单性，同时为 Web 应用程序、桌面应用程序、移动设备应用等提供了特定的授权流程。它在2012年取代了 OAuth 1.0, 并且 OAuth 2.0 协议不向后兼容 OAuth 1.0。

需要注意的是,OAuth 2.0 是一个授权(authorization)协议，而不是身份验证(authentication )协议。

Roles 角色
首先还需要了解一些概念, 因为整个OAuth授权流程都是围绕这些抽象的概念展开的, 角色是 OAuth2.0 授权框架核心规范的一部分, OAuth 定义了以下4种角色

•Resource Owner
资源所有者, 这里通常是拥有资源权限的用户或者系统。
•Client
客户端应用, 它可以通过访问令牌(Token)访问受保护资源, 可以是Web浏览器上的网站也可以是桌面应用或者手机App。
•Authorization Server
授权服务器, 在经过用户的授权后, 向客户端应用发放访问令牌(Access Token)。
•Resource Server
资源服务器, 存放受保护资源的服务器, 接受来自客户端(Client)请求的有效访问令牌(Access Token), 然后返回对应的资源。

Client Types 客户端类型
OAuth 2.0 核心规范定义了两种客户端类型, confidential 机密的, 和 public 公开的, 区分这两种类型的方法是, 判断这个客户端是否有能力维护自己的机密性凭据(password, client_secret)。

•confidential 对于一个普通的web站点来说,虽然用户可以访问到前端页面, 但是数据都来自服务器的后端api服务, 前端只是获取授权码code, 通过 code 换取access_token 这一步是在后端的api完成的, 由于是内部的服务器, 客户端有能力维护密码或者密钥信息, 这种是机密的的客户端。
•public 对于一个没有后端的纯前端应用来说(比如SPA), 数据的展示和操作都是在前端完成的, 包括获取令牌和操作令牌, 把一个客户端密码或者密钥放在纯前端应用是不安全的, 这种是公开的客户端。

Client Authentication 客户端身份认证
前面已经说过了, OAuth 2.0 是授权协议, 那为什么还要对 OAuth 2.0 客户端进行身份验证呢？身份验证和授权有什么区别？简单说身份验证确认用户是否是本人, 而授权则是授予用户访问资源的权限, 授权的前提条件一定是要先通过身份认证, 而且接下来的内容中, 也有用到了身份认证, 为了方便理解, 所以对认证做了简单的介绍。

授权服务器对客户端进行身份验证可以保证把令牌颁发给了合法的客户端, 但是认证其实已经超出了 OAuth2.0 的协议范围, 在 [RFC 6749] 中也只是简单介绍了以下2种认证方式:

第一种是使用 HTTP Basic [RFC2617] 中定义的身份验证方案进行身份认证, 这种方式叫 client_secret_basic, 首先需要对username,password 或者 client_id, client_secret 用冒号进行拼接。

{username}:{password} 或者 {client_id}:{client_secret} 就像这样 admin:123456
然后对字符串进行Base64编码, 然后设置为请求Header中的Authorization, 注意前面要拼接一个Basic和空格, 如下