Spring Security 集成 OAuth 2.0 认证（一）

01

集成介绍

OAuth 2.0 协议定义了如何能让第三方应用以有限的权限访问 HTTP 服务相关规范，可以通过构建资源拥有者与 HTTP 服务间的许可交互机制，让第三方应用代表资源拥有者访问服务，或者通过授予权限给第三方应用，让其代表自己访问服务。

Spring Security 是一个功能强大且高度可定制的身份验证和访问控制框架。它是用于保护基于 Spring 的应用程序的实际标准。它致力于为 Java 应用程序提供身份验证和授权。与所有 Spring 项目一样，Spring Security 的真正强大之处在于可以轻松扩展以满足自定义要求。

02

知识储备学习

OAuth2.0 概述

“
An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
”

OAuth（Open Authorization）是一个关于授权（authorization）的开放网络标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。OAuth 在全世界得到广泛应用，目前的版本是 2.0 版。

协议特点

简单：不管是 OAuth 服务提供者还是应用开发者，都很易于理解与使用。
安全：没有涉及到用户密钥等信息，更安全更灵活。
开放：任何服务提供商都可以实现 OAuth，任何软件开发商都可以使用 OAuth。

应用场景

原生 app 授权：app 登录请求后台接口，为了安全认证，所有请求都带 token 信息，需要登录验证、请求后台数据。
前后端分离单页面应用：前后端分离框架，前端请求后台数据，需要进行 OAuth 2.0 安全认证，比如使用 vue、react 或者 h5 开发的 app。
第三方应用授权登录，比如 QQ，微博，微信的授权登录。

概念

四种角色：

Resource owner：资源所有者，也叫用户
Resource server：资源服务器，服务提供商用来存储资源，以及处理对资源的请求的服务器
Client：客户端，也叫第三方应用，通过获取用户的授权，继而访问用户在资源服务器上的资源
Authorization server：认证服务器，服务提供商用来处理认证的服务器，物理上与资源服务器可以是同一台服务器

两种实体：
HTTP service：服务提供商
User Agent：用户代理，通常指浏览器

授权类型

OAuth 定义了四种获取授权的方式，客户端必须获取用户的授权，才能够获取令牌。本文主要讲解授权码模式，后续的文章介绍其他三种。

授权码模式（Authorization Code）
是功能最齐全、流程最严谨，也是最常用的授权模式。

1. 用户通过用户代理访问客户端，客户端将其重定向到认证服务器

response_type：表示授权类型，必选项，此种模式固定为 “code”

client_id：表示客户端 ID，必选项

redirect_uri：表示重定向 URI，可选项

scope：表示申请的权限范围，可选项

state：表示客户端当前状态，可选项

实例：

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
1
2
3

2. 用户选择是否授权给客户端

3. 如果用户授权，认证服务器将用户重定向到客户端事先指定的 URI，并附加一个授权码

code：表示授权码，必选项，客户端只能使用一次，与客户端 ID 和重定向 URI 一一对应

state：表示客户端的状态

实例：

HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
1

4. 客户端使用授权码和重定向 URI，向认证服务器申请令牌

grant_type：表示授权类型，必选项，此种模式固定为 “authorization_code”

code：

表示授权码，必选项

redirect_uri：

表示重定向 URI，必选项

client_id：表示客户端 ID，必选项

实例：

POST /token HTTP/1.1 Host: server.example.com 
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
Content-Type: application/x-www-form-urlencoded 
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
1
2
3
4
5
6

5. 认证服务器验证授权码和 URI，确认无误后，向客户端发放令牌

access_token：表示访问令牌，必选项

token_type：表示令牌类型，必选项，可以是 bearer 或 mac 类型

expires_in：表示过期时间，单位为秒。如果省略，则其他方式必须设置

refresh_token：表示刷新令牌，可选项，用来获取下一次的访问令牌

scope：表示权限范围，如果与客户端申请的范围一致，可省略

实例：

HTTP/1.1 200 OK 
Content-Type: application/json;charset=UTF-8 
Cache-Control: no-store 
Pragma: no-cache
{ 
    "access_token":"2YotnFZFEjr1zCsicMWpAA", 
    "token_type":"example", 
    "expires_in":3600, 
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
}
1
2
3
4
5
6
7
8
9
10
11

刷新令牌

如果用户访问的时候，客户端所获取的访问令牌已经过期，则需要使用刷新令牌重新申请新的访问令牌。

客户端发送的 HTTP 请求，包括以下参数：

grant_type：表示授权类型，必选项，此种模式固定为 “refresh_token”

refresh_token：表示之前收到的刷新令牌，必选项

scope：表示权限范围，不能够超出上次申请的范围。如果省略，则表示与上次申请的权限范围一致

实例：

POST /token HTTP/1.1 
Host: server.example.com 
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
Content-Type: application/x-www-form-urlencoded 
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

1
2
3
4
5
6

关于 Authing

Authing 是国内首款以开发者为中心的全场景身份云产品，为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品，Authing 在产品创建初期，目标就是服务亿级的企业和个人开发者客户，轻量级、易部署、低消耗、技术栈成熟，运维易的云原生技术产品架构，成为了 Authing 的首选。

点击此处了解更多行业身份管理

「解决方案」以及「最佳实践案例」