http - 当 session 在 OpenID Connect 设置中过期时，WWW-Authenticate 应该包含什么？

Question

场景:

app.com 已将身份验证委托(delegate)给 openid-connect.provider.com，这意味着未经身份验证的用户将被重定向到外部提供商进行登录，如果他们没有一个有效的 session 。一旦发生这种情况，他们就会在 app.com 上获得一个持续一段时间的 session cookie。

虽然用户流程很好，但我想知道如何处理 API 请求？规范说，如果您返回 HTTP 401 UNAUTHORIZED，它需要伴随一个 WWW-Authenticate header ，向客户端提供身份验证方案。

那么 app.com 在出现 401 时应该返回什么？

我看到 bits and pieces indicating OAuth ，但我想这与登录的外部提供商有关，而不是应用程序本身 (app.com)？

例子:

 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: Bearer realm="example",
                   error="invalid_token",
                   error_description="The access token expired"

上面的内容似乎不对，因为 app.com 服务器不使用任何 oauth 意义上的访问 token ，只是本地 session 的普通 session cookie。

Answer 1

当 session cookie 过期时重定向到 OIDC 登录是 UI 前端应用程序广泛使用的做法。关于此处使用的 cookie，我认为它与 OIDC 流获得的访问 token 相关(例如:- cookie 生命周期匹配访问 token 生命周期)。

关于 API 访问，我相信上述 API 使用通过 RFC6750 定义的不记名 token 用法.此 RFC 定义如何在后续 protected API 调用中使用 token 。其中一个重要部分是 The WWW-Authenticate Response Header Field 部分定义 token 无效或过期时要执行的操作。您找到的答案和您在问题中提到的示例与 RFC 建议的解释相关。

我认为问题归结为您如何针对您的 API 进行身份验证。如果您的 API 遵循不记名 token 的使用，则遵循您的示例。将 HTTP 状态代码与 WWW-Authenticate 一起使用。这将带来规范合规性。

但是如果有自定义身份验证机制(例如:- cookie)，那么它就超出了规范的范围。但是您可以获得来自 API 的 JSON 响应，其中包含错误详细信息(例如:- Http 代码、原因、描述和用于调试的相关 ID)。我会说 WWW-Authenticate header 在这种情况下是可选的。