OAuth 2.0 访问令牌获取与使用指南
在确保 Eureka 服务器的访问得到保护后,我们将学习如何颁发 OAuth 访问令牌。下面将详细介绍获取访问令牌的方法、使用访问令牌调用受保护的 API,以及使用外部 OpenID Connect 提供商进行测试的相关内容。
1. 获取访问令牌
我们可以使用 OAuth 2.0 定义的授权流程来获取访问令牌,主要介绍客户端凭证授权流程和授权码授权流程。
1.1 客户端凭证授权流程获取访问令牌
- 为 writer 客户端获取访问令牌 :要获取具有
product:read和product:write范围的 writer 客户端的访问令牌,可使用以下命令:
curl -k https://writer:secret-writer@localhost:8443/oauth2/token -d grant_type=client_credentials -d scope="product:read product:write" -s | jq .
客户端使用 HTTP 基本身份验证来标识自己,传递其客户端 ID(writer)和客户端密钥(secret)。示例响应包含以下信息:
| 信息 | 详情 |
| ---- | ---- |
| 访问令牌本身 | 用于访问受保护资源的令牌 |
| 授予令牌的范围 | product:write 、 product:read 和 openid 范围 |
| 令牌类型 | Bearer,持有此令牌的人应根据授予的范围获得访问权限 |
| 访问令牌的有效期 | 3599 秒 |
- 为 reader 客户端获取访问令牌 :要获取仅具有
product:read范围的 reader 客户端的访问令牌,只需将上述命令中的writer替换为reader:
curl -k https://reader:secret-reader@localhost:8443/oauth2/token -d grant_type=client_credentials -d scope="product:read" -s | jq .
1.2 授权码授权流程获取访问令牌
此授权流程需要涉及 Web 浏览器,以在部分不安全的环境(Web 浏览器)中确保安全性。执行步骤如下:
1. 在接受自签名证书的 Web 浏览器(如 Chrome)中使用以下 URL 为 reader 客户端获取授权码:
https://localhost:8443/oauth2/authorize?response_type=code&client_id=reader&redirect_uri=https://my.redirect.uri&scope=product:read&state=35725
- 当 Web 浏览器要求登录时,使用授权服务器配置中指定的凭据
u和p。 - 系统会要求我们给予 reader 客户端以我们的名义调用 API 的权限。
- 点击“Submit Consent”按钮后,会得到一个响应。将返回的 URL 复制到文本编辑器中,从中提取授权码,并定义环境变量
CODE:
CODE=7XBs...0mmyk
- 模拟后端服务器,使用以下
curl命令将授权码交换为访问令牌:
curl -k https://reader:secret-reader@localhost:8443/oauth2/token \
-d grant_type=authorization_code \
-d client_id=reader \
-d redirect_uri=https://my.redirect.uri \
-d code=$CODE -s | jq .
响应信息与客户端凭证流程类似,但有以下不同:
- 由于使用了更安全的授权流程,还会颁发刷新令牌。
- 由于请求的是 reader 客户端的访问令牌,所以只有 product:read 范围,没有 product:write 范围。
- 为 writer 客户端获取授权码,使用以下 URL:
https://localhost:8443/oauth2/authorize?response_type=code&client_id=writer&redirect_uri=https://my.redirect.uri&scope=product:read+product:write&state=72489
- 为 writer 客户端将授权码交换为访问令牌,运行以下命令:
curl -k https://writer:secret-writer@localhost:8443/oauth2/token \
-d grant_type=authorization_code \
-d client_id=writer \
-d redirect_uri=https://my.redirect.uri \
-d code=$CODE -s | jq .
验证响应中是否包含 product:write 范围。
2. 使用访问令牌调用受保护的 API
OAuth 2.0 访问令牌应作为标准的 HTTP 授权头发送,访问令牌前需加上 Bearer 。以下是调用受保护 API 的示例:
1. 使用无效访问令牌调用 API :
ACCESS_TOKEN=an-invalid-token curl https://localhost:8443/product-composite/1 -k -H "Authorization: Bearer $ACCESS_TOKEN" -i
将返回 401 Unauthorized 响应,错误消息表明访问令牌无效。
- 使用 reader 客户端的有效访问令牌调用 API :
ACCESS_TOKEN={a-reader-access-token} curl https://localhost:8443/product-composite/1 -k -H "Authorization: Bearer $ACCESS_TOKEN" -i
将返回 200 OK 状态码和预期的响应体。
- 使用 reader 客户端的访问令牌尝试访问更新 API(如删除 API) :
ACCESS_TOKEN={a-reader-access-token} curl https://localhost:8443/product-composite/999 -k -H "Authorization: Bearer $ACCESS_TOKEN" -X DELETE -i
将失败,返回 403 Forbidden 结果,因为请求需要比访问令牌授予的更高权限。
- 使用 writer 客户端的访问令牌调用删除 API :
ACCESS_TOKEN={a-writer-access-token} curl https://localhost:8443/product-composite/999 -k -H "Authorization: Bearer $ACCESS_TOKEN" -X DELETE -i
调用将成功,响应为 202 Accepted。
3. 使用 Swagger UI 与 OAuth 2.0 进行测试
要使用 Swagger UI 组件访问受保护的 API,可按以下步骤操作:
1. 在 Web 浏览器中访问以下 URL 打开 Swagger UI 起始页面:
https://localhost:8443/openapi/swagger-ui.xhtml
- 在起始页面上,点击“Authorize”按钮启动授权码授权流程。
- Swagger UI 将显示一个范围列表,点击“select all”链接选择所有范围,然后点击“Authorize”按钮。
- 使用用户名
u和密码p登录。 - 授权服务器会要求您同意,选择两个范围并点击“Submit Consent”按钮。
- Swagger UI 将完成授权过程,点击“Close”按钮返回起始页面。
- 现在可以像之前描述的那样尝试使用 API,Swagger UI 会将访问令牌添加到请求中。
4. 使用外部 OpenID Connect 提供商进行测试
我们将使用 Auth0 作为外部 OpenID 提供商进行测试,具体步骤如下:
4.1 在 Auth0 中设置和配置账户
- 在浏览器中打开 https://auth0.com 。
- 点击右上角的汉堡菜单(☰),然后点击“Sign up”按钮。
- 使用您选择的电子邮件注册。
- 注册成功后,创建租户域(如 dev-ml-3rd.eu.auth0.com)。
- 按要求填写账户信息。
- 查看邮箱中主题为“Please Verify Your Auth0 Account”的邮件,按说明验证账户。
- 注册后,进入引导页面。
- 在左侧菜单中,点击“Applications”展开,然后点击“APIs”找到管理 API(Auth0 Management API)。
- 点击“Auth0 Management API”并选择“Test”选项卡。
- 点击“Create & Authorize Test”按钮创建一个可用于访问管理 API 的客户端。
- 完成创建后,授予创建的客户端使用管理 API 的权限。
- 点击“Machine to Machine Applications”选项卡。
- 点击“All”选项,然后点击“Update”按钮。
- 点击“Continue”按钮。
-
收集创建的客户端的客户端 ID 和客户端密钥。
- 在左侧菜单中选择“Applications”,然后选择“Auth0 Management API (Test Application)”。
- 打开文件
$BOOK_HOME/Chapter11/auth0/env.bash,将以下值复制到文件中:- 域名复制到
TENANT变量的值中。 - 客户端 ID 复制到
MGM_CLIENT_ID变量的值中。 - 客户端密钥复制到
MGM_CLIENT_SECRET变量的值中。
- 域名复制到
- 在
env.bash文件中指定测试用户的电子邮件地址和密码(USER_EMAIL和USER_PASSWORD)。
-
运行以下命令创建所需的定义:
cd $BOOK_HOME/Chapter11/auth0
./setup-tenant.bash
保存输出末尾打印的导出命令副本,查看测试用户邮箱中主题为“Verify your email”的邮件,按说明验证用户的电子邮件地址。
4.2 应用使用 Auth0 作为 OpenID 提供商所需的更改
在 product-composite 和 gateway 项目中,更新 application.yml 文件中的 OIDC 发现端点,使其指向 Auth0 而不是本地授权服务器:
1. 找到属性 spring.security.oauth2.resourceserver.jwt.issuer-uri 。
2. 将其值替换为 https://${TENANT}/ ,其中 ${TENANT} 应替换为您的租户域名(如 dev-ml.eu.auth0.com),不要忘记末尾的 / 。
例如,配置可能如下所示:
spring.security.oauth2.resourceserver.jwt.issuer-uri: https://dev-ml.eu.auth0.com/
如果您想查看发现文档的内容,可以运行以下命令:
curl https://${TENANT}/.well-known/openid-configuration -s | jq
通过以上步骤,您可以完成使用 OAuth 2.0 进行访问令牌的获取、使用,以及与外部 OpenID Connect 提供商的集成测试。
OAuth 2.0 访问令牌获取与使用指南(续)
5. 技术点分析与总结
5.1 不同授权流程对比
| 授权流程 | 适用场景 | 安全性 | 操作复杂度 |
|---|---|---|---|
| 客户端凭证授权流程 | 客户端与资源服务器之间的直接交互,无需用户参与,如服务器间的定时任务 | 较低,依赖客户端 ID 和密钥保护 | 简单,只需发送请求获取令牌 |
| 授权码授权流程 | 需要用户授权的场景,如用户登录第三方应用访问资源 | 较高,引入授权码和刷新令牌机制 | 复杂,涉及浏览器交互、用户登录和授权等步骤 |
5.2 访问令牌使用规则
- 范围限制 :不同客户端的访问令牌具有不同的范围,如
product:read和product:write,客户端只能访问其令牌范围内的资源。 - 令牌格式 :OAuth 2.0 访问令牌作为标准的 HTTP 授权头发送,格式为
Bearer <access_token>。 - 有效期 :访问令牌有一定的有效期,超过有效期后需要重新获取或使用刷新令牌刷新。
5.3 外部 OpenID 提供商集成要点
- 账户配置 :在 Auth0 中需要完成注册、创建租户、配置管理 API 客户端等步骤,确保客户端具有访问管理 API 的权限。
- 配置更改 :在使用 Auth0 作为 OpenID 提供商时,需要更新 OAuth 资源服务器(如
product-composite和gateway服务)的配置,指向 Auth0 的 OIDC 发现端点。
6. 操作流程图
graph TD;
A[开始] --> B{选择授权流程};
B --> C[客户端凭证授权流程];
B --> D[授权码授权流程];
C --> C1[发送请求获取令牌];
C1 --> C2[使用令牌访问 API];
D --> D1[使用浏览器获取授权码];
D1 --> D2[登录并授权];
D2 --> D3[提取授权码];
D3 --> D4[交换授权码为令牌];
D4 --> D5[使用令牌访问 API];
C2 --> E{令牌是否有效};
D5 --> E;
E --> F[有效,继续操作];
E --> G[无效,重新获取令牌];
G --> B;
此流程图展示了获取访问令牌和使用令牌访问 API 的整体流程,包括不同授权流程的选择、令牌有效性检查以及令牌无效时的处理。
7. 故障排除与注意事项
7.1 令牌获取失败
- 客户端凭证错误 :检查客户端 ID 和密钥是否正确。
- 授权码过期 :授权码只能使用一次,若过期需要重新获取。
- 权限不足 :确保客户端具有获取相应范围令牌的权限。
7.2 API 访问失败
- 令牌无效 :检查令牌是否过期或格式是否正确。
- 范围不足 :确保使用的令牌具有访问 API 所需的范围。
- 服务器配置问题 :检查 OAuth 资源服务器的配置是否正确,如 OIDC 发现端点是否指向正确的提供商。
7.3 外部提供商集成问题
- 账户配置错误 :检查在 Auth0 中的账户配置是否正确,如管理 API 客户端的权限是否设置正确。
- 配置文件更新 :确保在 OAuth 资源服务器中正确更新了指向 Auth0 的配置。
8. 未来展望
随着 OAuth 2.0 和 OpenID Connect 技术的不断发展,未来可能会出现更安全、更便捷的授权方式。例如,多因素认证的集成、基于区块链的令牌验证等。同时,与更多外部 OpenID 提供商的集成也将变得更加容易,为开发者提供更多的选择。
通过深入理解 OAuth 2.0 的授权流程、访问令牌的使用以及与外部 OpenID 提供商的集成,开发者可以更好地保护应用程序的资源,确保用户数据的安全。希望本文对您在实际项目中的应用有所帮助。

3万+

被折叠的 条评论
为什么被折叠?



