我一直在阅读文档,但我仍然有点困惑
流程适用于每个 API 请求
API 不应该遵循 OpenID 连接协议。应该由客户来做。
我的后端 API 在 HTTP 标头中看到授权代码,并且
向授权服务器发送请求以获取 id 令牌。
假设这验证 OK,请求的数据在 API 中返回
回应。
授权代码必须由客户端应用程序使用,而不是由 API 端点使用。此外,授权代码绝不能暴露给其他实体。
您应该使用随 OpenID Connect 发送的 id 令牌来验证来自您的客户端应用程序的最终用户。要访问 API,您应该使用访问令牌。
API端点做什么?
我认为这就是你挣扎的地方。您的客户端应用程序应发送有效的访问令牌以访问 API 端点。从 API 端点,您可以使用 OAuth 2.0 自省端点来验证令牌。
RFC7662 - OAuth 2.0 Token Introspection
本规范定义了一个允许授权的协议
受保护的资源查询授权服务器以确定
给定令牌的元数据集,由
OAuth 2.0 客户端。
请注意,OpenID Connect 建立在 OAuth 2.0 之上。这意味着您可以使用 OAuth 2.0 中定义的任何内容,包括自省端点。使用此端点验证访问令牌的有效性。
如果您需要最终用户详细信息怎么办?
OpenID Connect 定义了一个用户信息端点
User info endpoint
UserInfo 端点是一个 OAuth 2.0 受保护资源,它返回有关经过身份验证的最终用户的声明。为了获得有关最终用户的请求声明,客户端使用通过 OpenID Connect 身份验证获得的访问令牌向 UserInfo 端点发出请求。这些声明通常由一个 JSON 对象表示,该对象包含声明的名称和值对集合。
在这里,您还可以使用访问令牌从该端点获取用户信息。响应将让您知道该令牌被发给的最终用户。
根据您的特定 API 要求,您可以进行令牌自省或从用户信息端点获取用户信息。完成后,您可以继续验证会话。如果您需要所有可用信息,您可以同时使用这两个端点。
或者(而不是会话)您的 API 可以维护访问令牌缓存。这将消除在每个 API 调用中验证令牌的需要。但请注意,令牌有过期时间。如果您选择此解决方案,则必须考虑令牌过期问题。
p.s - 客户端与资源服务器
在 OpenID Connect 和 OAuth 2.0 术语中,客户端可以是简单的网页、桌面应用程序,甚至可以是服务器托管的应用程序。
客户
代表受保护资源请求的应用程序
资源所有者及其授权。 “客户”一词确实
不暗示任何特定的实现特征(例如,
应用程序是否在服务器、桌面或其他设备上执行
设备)。
获取令牌并使用它们是客户端应用程序的职责。
另一方面,资源服务器包含受保护的资源,
资源服务器
托管受保护资源的服务器,能够接受
并使用访问令牌响应受保护的资源请求。
资源服务器交换它的资源来访问令牌。如果我们将相同的场景与基本身份验证相匹配,访问令牌将替换使用身份验证标头发送的用户名/密码。