剖析Web系统中OAuth2的应用
前言
在日常的开发工作里，系统常常需要作为对接方或者被对接方去和别的系统做集成。这类集成的首要步骤一般是身份认证，其中OAuth 2.0认证是比较常见的。本文打算跳过繁琐的定义和规范解读，着重围绕两个典型的应用场景，来讲讲OAuth 2.0的实际落地设计思路。
单点登录（Single Sign-On, SSO）
单点登录场景通常采用授权码模式（Authorization Code Grant）。该模式的关键之处在于用户授权之后，系统才能够获取到用户的登录信息。授权既可以是显式的（需要用户确认），也可以是隐式的（用户没有感知）。
– 显式授权示例：登录某个游戏的微信公众号来进行日常签到，需要用户在弹出的授权窗口明确进行确认。
– 隐式授权示例：某集团的OA系统集成独立的财务子系统，用户从平台跳转到财务系统就可以进行操作，不需要二次登录或者确认。
下面以“平台方作为业务大平台，为第三方应用提供单点登录接入能力”为例来进行说明（要是角色互换为应用接入其他平台，设计思路是类似的）：
1. 应用注册：
– 平台方得提前存储要接入应用的相关信息，包含应用名称、能唯一标识应用的应用密钥（App Key和Secret）、还有应用的回调地址（用来接收授权码的重定向地址）。
2. 获取授权码（Authorization Code）：
– 用户在平台内点击跳转到目标应用。平台会生成一个和该用户绑定的、有时效性的（一般是5 – 10分钟）授权码code，并且把它添加在跳转地址里传递给应用。
– 这个code通常是一次性使用的，过期就会失效。可以把它当作键（Key），用户信息当作值（Value）存储到Redis等缓存中，并且设置自动过期策略。
3. 获取访问凭据（Access Token）：
– 应用使用接收到的code，结合自身的App Key和Secret向平台认证服务发起请求，来换取访问凭据（Access Token）。
– 换取成功之后，code马上就会失效。应用可以把用户信息和这个Token绑定存储到缓存中。
– Token本身通常也有有效期（比如8到24小时），部分系统提供Token刷新接口来延长有效期。
4. 获取用户信息：
– 应用凭借有效的Access Token就能够调用平台提供的接口来获取用户基本信息（像用户ID、用户名等，具体范围根据需求而定）。
– 如果涉及敏感数据，能够在应用注册阶段约定加密密钥，对传输的数据进行加密处理。
5. 获取扩展信息：
– 对于网站注册类的应用，获取基础用户信息一般就足够了。
– 对于像OA的管理系统集成，就需要平台额外提供获取组织架构信息（比如租户、部门、人员、角色及其关系等）的接口，来支撑业务流程对接。
数据共享（API集成）
数据共享场景通常采用客户端模式（Client Credentials Grant）。此模式允许应用直接使用自身的App Key和Secret来换取访问凭据，从而访问授权范围内的资源接口，省去了获取用户授权码的步骤。
下面以“集成API开放平台为用户提供不同数据资源”为例来进行说明：
1. 应用注册：
– 在平台注册应用信息，明确勾选该应用有权访问的数据资源（也就是对应的API接口）。
– 平台会自动生成用于标识该应用的App Key和Secret。
2. 获取访问凭据（Access Token）：
– 应用直接使用自身的App Key和Secret向平台认证服务发起请求，来换取访问凭据。
– 这个Token和应用绑定，它的访问权限严格限制在注册时勾选的资源接口范围之内。
3. 访问资源接口：
– 应用在调用授权的资源接口的时候，需要在请求头部（比如Authorization头）携带有效的Access Token来进行认证。
– 平台可以根据注册的应用信息实施访问控制策略，比如限制接口调用频率或者单次请求的数据量上限。
