OAuth 2实战指南（原理、工程实践、代码落地）.docVIP

OAuth2

实战指南

原理、工程实践、代码落地

目录

TOC\h\h第1章OAuth2概述

\h第2章开放平台整体架构

\h第3章实战中的授权模式

\h第4章OpenID从理论到实战

\h第5章授权码授权模式回调地址实战

\h第6章签名

\h第7章授权信息

\h第8章基于SpringSecurity的OAuth2实战

第1章

OAuth2概述

OAuth2为用户资源的授权提供了一个开放、安全的标准，因此用户在授权时不需要提供用户名和密码，就能授权第三方应用访问资源。OAuth2是OAuth协议的延续版本，不向下兼容。本章首先介绍OAuth2的定义，然后介绍OAuth2提出的四种授权模式，包括隐式授权模式、授权码授权模式、授信客户端密码模式，以及授信客户端模式。

1.1OAuth2的定义

1.1.1官方定义

OAuth2是一个标准的授权协议，并以委派代理的方式进行授权。OAuth2提供一种协议交互框架，使第三方应用以安全的方式，获得用户的访问令牌（access_token）。第三方应用可以使用访问令牌代表用户访问相关资源。OAuth2中定义了以下4种角色。

·资源所有者：通常是自然人，但不限于自然人，如某些应用程序也会创建资源。资源所有者对资源拥有所有权。

·资源服务器：存储受保护的用户资源。

·应用程序：准备访问用户资源的程序，如Web应用、移动端应用或桌面可执行程序。

·授权服务器：在获取用户授权后，为应用程序颁发访问令牌，从而获取用户资源。

1.1.2开放平台中的定义

开放平台的核心功能是将开放平台所在系统（简称开放系统）的功能和数据暴露给第三方应用，从而实现能力共建的目标。有的功能和数据与开放系统的用户无关，有的功能和数据与开放系统的用户息息相关，主要包括以下两种开放场景。

·在第一种开放场景中，只有第三方应用和开放平台参与。在这种场景下，开放系统需要对第三方应用进行验证，从而明确对第三方应用开放功能和数据的范围。

·在第二种开放场景中，开放系统的用户也参与其中。开放系统在验证第三方应用的功能和数据的访问权限后，需要开放系统的用户进行授权。只有开放系统的用户授权后，开放平台才能将对应的功能和数据开放给第三方应用。

在这两种开放场景中，都将特定的功能和数据开放给第三方应用，因此OAuth2定义了完整的交互流程，以便支撑这些开放能力的请求和授予。

在上述过程中，提到的关键角色包括开放平台、开放系统的用户和第三方应用，而两个关键信息包括功能和数据。

·开放平台：开放平台服务于所依赖的开放系统，用于建立开放系统与第三方应用之间的沟通桥梁。

·开放系统的用户：开放系统所拥有的用户，这些用户使用开放系统所提供的某些功能。开放系统拥有这些用户的相关数据和数据的操作能力。

·第三方应用：除开放平台企业之外的其他公司开发的应用。这些应用会在开放平台申请账号，并基于该账号与开放平台进行对接，最终通过开放平台所开放的能力实现某些功能。

注：第三方应用和开放平台不在同一家公司，无法共享开放平台的账号体系。

·功能：开放系统提供的API，通过开放平台提供的第三方应用进行调用，通常为权限包的形式。第三方应用在对接开放平台时，会申请相应的权限包，并且在由开放平台的运营人员审核通过后，即可获得相应的权限包。

注：通常权限包与scope权限之间存在对应关系，一个scope权限通常会对应一个或多个权限包。

·数据：用户在开放系统中的信息，是用户对外的唯一标识，包括昵称、头像、手机号码、家庭住址和相关的业务信息。在开放平台中，用scope参数表示获取信息的范围和申请的权限。

注：在申请和授予权限时，可以指定多个scope权限。

1.2OAuth2的四种授权模式

1.2.1隐式授权模式

1.授权请求示例

步骤1隐式授权（ImplicitGrant）模式引导用户在登录页面登录，在用户登录成功后，通过授权系统将用户的授权信息回调到第三方应用，在第三方应用拿到授权信息后，便可调用开放能力。隐式授权请求如示例1.1所示。

示例1.1隐式授权请求

注意

在这里统一说明一下，示例中使用“##”代表一个参数值，后文均遵循该规则。

示例1.1中各参数的含义如下。

·client_id：第三方应用在开放平台注册完成后获取的唯一标识。

·redirect_url：第三方应用在开放平台注册的回调地址。

·scope：第三方应用的访问权限，一般由逗号分隔的多个字符串组成。

·response_type：默认值为token，即返回授权的token。

步骤2假设第三方应用设置的回调地址为/callback，在第三方应用引导用户发起步骤1后，会跳转到用户登录页面。在