OAuth 2.0认证授权设计
如图4-43所示，在App端可以选择微信登录，点击“微信”图标会唤醒手机中的微信App，询问用户是否同意授权，用户点击“同意”按钮就代表授权通过，则用户的头像、性别、用户ID等信息就会授权给第三方使用，对于在Web端的微信扫码登录，原理也是相同的。
图4-43 第三方账号登录原型
无论是授权绑定还是授权登录，本质上使用的都是OAuth 2.0协议。OAuth 2.0协议是当前认证授权的行业标准，其重点在于为Web应用程序、桌面应用程序、移动设备及室内设备的授权流程提供简单的客户端开发方式。
1. OAuth 2.0 协议的4种角色
在OAuth 2.0协议中包含4种角色，它们之间相互协作才能够对系统提供安全的认证授权流程。
（1） Resource Owner（资源所有者）：是能够对受保护资源授予访问权限的实体，可以是一个用户。例如，用户把钱存在银行中，钱是资源，而用户才是资源所有者，并不是银行。
（2） Resource Server（资源服务器）：持有受保护资源，允许持有访问令牌的请求访问受保护资源。例如，对于银行或银行的管理系统来说，银行或银行的管理系统才是资源服务器，它们持有受保护资源，只有有权限的个人或银行柜员才可以操作。
（3） Client（客户端）：持有资源所有者的授权，代表资源所有者对受保护资源进行访问。例如，手机银行App，它就是客户端，它通过用户的授权代表用户对账户中的资金进行操作。
（4） Authorization Server（授权服务器）：对资源所有者的授权进行认证，成功后向客户端发放访问令牌。例如，银行的认证授权系统、账户管理系统，只有通过账号和密码的正确认证，才会允许对账户进行操作。
2. OAuth 2.0 协议的工作原理
OAuth 2.0的认证授权流程如图4-44所示，分为以下6个步骤。
（1）客户端请求资源所有者的授权。（2）资源所有者同意授权，返回授权许可（Authorization
Grant），这代表了资源所有者的授权凭证。
（3） 客户端携带授权许可要求授权服务器进行认证，请求访问令牌。
（4） 授权服务器对客户端进行身份验证，并认证授权许可，如果有效，则返回访问令牌。
（5） 客户端携带访问令牌向资源服务器申请对受保护资源进行访问。
（6） 资源服务器验证访问令牌，如果有效，则接受访问请求，返回受保护资源。
图4-44 OAuth 2.0的认证授权流程
3. OAuth 2.0 协议的工作流程举例
下面以淘宝手机App为例，详细讲解OAuth 2.0协议的工作流程，首先分析出4种角色分别是谁。
（1） 资源所有者：淘宝用户，拥有所有的订单、账户余额、积分等资源。
（2） 资源服务器：淘宝后台系统，保护用户的资源，只允许用户本人操作这些资源。
（3） 客户端：淘宝手机App，代表用户与淘宝后台系统交互。
（4） 授权服务器：淘宝认证授权管理系统，用于验证用户名和密码的正确性，发放访问令牌。
4种角色的协作流程分为6个步骤，具体如下。
（1） 客户端请求资源所有者授权，这时打开淘宝登录页面，淘宝要求输入用户名和密码。这个过程就是客户端（淘宝手机App）请求资源所有者（用户）授权（输入用户名和密码）。
（2） 资源所有者同意授权，即用户录入了用户名和密码，并且点击“登录”按钮，表示同意了授权。把个人许可（用户名和密码）交给了客户端。
（3） 客户端携带个人许可去请求授权服务器认证，即携带着用户名和密码去请求授权服务器验证用户名和密码是否匹配。
（4） 授权服务器验证用户名和密码是否正确，如果正确，则返回访问令牌；如果不正确，则拒绝授权。
（5） 此时用户成功登录，去查看自己的订单，则携带访问令牌去请求淘宝后端服务。（6）资源服务器验证令牌有效性，如果有效，则返回用户的订单信息。
4. OAuth 2.0 协议的4种模式
OAuth 2.0协议共有4种常用模式：授权码模式、简化模式、密码模式和客户端模式，安全性依次从高到低。
（1）授权码模式。
一般的第三方账号登录，如QQ登录、微信登录、微博登录等都采用授权码模式实现，此种模式流程最为复杂，安全性也最高。下面以某网站使用微信扫码登录为例，详细讲解授权码模式的原理，如图4-45 所示。
图4-45 微信扫码登录流程
微信扫码登录流程包含8个步骤，授权码模式交互流程如图4-46所示。
① 第1~2步：在某网站（客户端）上点击“微信登录”，这时会弹出浏览器（用户代理）页面，并重定向到授权二维码页面，此处需要注
意的是，这个二维码页面是微信的授权服务器提供的地址（如
② 第3~4步：二维码页面展示给用户，并提示用户使用微信扫码，本质上属于请求用户授权的过程。当用户扫码完成之后，在手机微信中点击“同意”按钮，代表用户同意授权。
③ 第5~6步：用户同意之后，二维码弹框关闭，认证授权中心会在重定向地址后增加授权码（Authorization Code）参数，如
code=1X3s4T。经过浏览器（用户代理）将授权码返回给客户端。
④ 第7~8步：客户端再携带授权码和重定向地址，去请求微信的授权服务器，授权服务器验证重定向地址和授权码匹配并且正确，则生成访问令牌给客户端，并重定向到客户端的指定页面，如网站首页。后续如果再与微信进行交互，则只提供访问令牌即可。访问令牌是具有有效期的，为了保持令牌有效，客户端需要定时刷新令牌。
图4-46 授权码模式交互流程
（2） 简化模式。
简化模式只是授权码模式的一种简化。在授权码模式中，需要先获取授权码，再使用授权码去获得访问令牌。而简化模式省略了这个步骤，在用户授权后就直接将访问令牌返回给客户端，其余流程完全一致。简化模式交互流程如图4-47所示。
图4-47 简化模式交互流程
（3） 密码模式。
密码模式是大多数系统采用的模式，用户直接在客户端页面上录入用户名和密码，由客户端携带客户端凭证（客户端标识）、用户名和密码去请求授权服务器，授权服务器验证客户端是否可信，用户名和密码是否正确；如果验证无误，则返回访问令牌，客户端携带访问令牌即可进行资源访问。密码模式交互流程如图4-48所示。
图4-48 密码模式交互流程
使用密码模式要求用户对客户端有足够的了解和信任，因为用户会将用户名和密码直接交给客户端，如果使用了一个假的银行软件，那么后果可想而知。所以，在密码模式中才必须携带客户端凭证，授权服务器需要确保接收的请求来自可以信任的客户端。
（4） 客户端模式。
客户端模式最为简单，只需要携带客户端凭证就可以访问，如
SecretID和SecretKey模式。这种模式一般只允许内网和专线访问，或者添加了访问白名单的系统使用，以及无须用户授权的开放式系统使
用。互联网应用如果使用客户端模式就需要极为慎重。客户端模式交互流程如图4-49所示。
图4-49 客户端模式交互流程