ID令牌的用途

Question

RP 从 OP 接收令牌（ID/访问/刷新令牌）并验证 ID 令牌后，RP 是否应将 ID 令牌存储在资源所有者的会话中？

如果是，使用 ID 令牌的目的是什么？

我认为应该出于以下原因存储访问和刷新令牌，例如：

• 访问令牌：用于从 Userinfo 端点获取用户信息。
• 刷新令牌：用于获取访问令牌后的另一个访问令牌 已过期。

Answer 1

答案取决于身份提供者（Google、Auth0、IBM、Twitter 等）。

在 OAuth 2.0 中，返回两个令牌：访问令牌和可选的刷新令牌。

访问令牌用于授权访问。这可能允许也可能不允许您从 userinfo 端点访问身份信息。身份令牌确实包含此信息。访问令牌可以是不透明的令牌，这意味着令牌中没有存储可以解码的信息，也可以是签名的 JWT。信息的数量和类型是特定于身份提供者的。访问令牌是短暂的，通常会在 3600 秒后过期。 Access Token不需要存储，除了本地缓存，因为过期后就没有价值了。

刷新令牌用于创建新的访问令牌。结合 OAuth 2.0 Client ID 和 Client Secret，您可以创建 Access Tokens，直到 Refresh Token 过期或失效。

OIDC (OpenID Connect) 在 OAuth 2.0 之上添加身份。 OIDC 提供一个身份令牌，该身份令牌提供 OAuth 范围请求的用户信息，并由拥有该身份的用户批准。大多数身份提供者通过他们的 OAuth 实现来实现 OIDC。身份令牌也会过期并且可以撤销。

在 Google Cloud 中，您可以使用身份令牌来提供基于身份的访问。您将具有角色的身份（电子邮件地址）分配给服务（计算引擎实例或云存储对象）。如果 HTTP 标头“Authorization: Bearer”存在、有效且与电子邮件地址匹配，则根据分配给该服务的身份的角色授予访问权限。

将 OAuth 令牌存储在 Web 会话中是一种糟糕的安全做法，除非每个会话都进行唯一加密。更好的做法是将 OAuth 令牌存储在数据库中，并在需要时使用存储在 Web 会话中的不透明 ID 进行查找。

并非所有身份提供者都支持所有 OAuth 授权类型的刷新令牌。这称为“离线”访问，可能会被拒绝，这意味着一旦访问令牌过期，用户将需要再次授权您的应用。