openid-connect - ID token 的用途

Question

RP 从 OP 收到 token (ID/访问/刷新 token )并验证 ID token 后，RP 是否应该将 ID token 存储在资源所有者的 session 中？

如果是，ID token 的用途是什么？

我认为应该存储访问和刷新 token ，原因如下，例如:

• 访问 token :用于从 Userinfo 端点获取用户信息。
• 刷新 token :用于在访问 token 被刷新后获取另一个访问 token 过期了。

Answer 1

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

在 OAuth 2.0 中，返回了两个 token :访问 token 和可选的刷新 token 。

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

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

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

在 Google Cloud 中，您可以使用身份 token 来提供基于身份的访问。您将具有角色的身份(电子邮件地址)分配给服务(Compute Engine 实例或 Cloud Storage 对象)。如果 HTTP header “Authorization: Bearer”存在、有效且与电子邮件地址匹配，则根据分配给该服务身份的角色授予访问权限。

将 OAuth token 存储在网络 session 中是一种糟糕的安全做法，除非每个 session 都进行了唯一加密。更好的做法是将 OAuth token 存储在数据库中，并在需要时使用存储在网络 session 中的不透明 ID 来查找它们。

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