OAuth 2.0 通过访问令牌进行身份验证答案

【问题标题】：OAuth 2.0 flow to authentication via access tokenOAuth 2.0 通过访问令牌进行身份验证
【发布时间】：2022-02-09 01:59:16
【问题描述】：

我有一个获取 JWT 访问令牌的公共客户端。我需要它来获取另一个（不是刷新，而是出于其他目的），并且我需要它在没有用户交互的情况下完成它。

因此，我试图弄清楚是否有一个标准的 OAuth 流，我可以在其中使用 (JWT) 访问令牌（在以前的 OAuth 流中发布）用于对另一个 OAuth 流进行身份验证（我可以' t 使用客户端密钥进行身份验证，因为它是公共客户端）。

我发现的所有东西都不是完美的匹配。

它确实允许通过 JWT 令牌进行身份验证。但是，它需要客户端颁发 JWT 令牌（由客户端拥有的证书签名）并检查签名。因此，我无法使用授权服务器为此目的颁发的 JWT 访问令牌。

这个允许使用 JWT 访问令牌并获取另一个 JWT 访问令牌。如此接近，但没有雪茄。此流程中不使用 JWT 访问令牌进行身份验证。因此，您仍然需要客户端 ID + 客户端密码来进行身份验证

这一个可能可以使用它。只需使用刷新令牌来获取新的 JWT 访问令牌。但是，它感觉很hacky。（我可能需要经常执行此操作，因此，感觉就像是在滥用令牌刷新机制。另外，我的猜测是它会逐渐用使用过的刷新令牌污染数据库（这是一个很小的次要问题，但是，再次这个解决方案感觉很老套）。

我错过了什么吗？

【问题讨论】：

【解决方案1】：

令牌交换适合您的用例，客户端身份验证部分是可选的：

支持的客户端身份验证方法以及是否允许部署未经身份验证或身份不明的客户端由授权服务器自行决定。

这样您就可以将它与您的公共客户端一起使用。列出的其他选项并不意味着以您需要的方式使用。

【讨论】：

【解决方案2】：

为什么需要避免第二个令牌请求的“用户交互”？我可以理解这种愿望（减少干扰等），但背后的原因是什么？

基于用户的 OAuth 流程将需要使用用户凭据进行身份验证。剩下的就是密码流程或授权代码流程。

密码意味着您需要用户的凭据才能发送...我假设您不需要（也不应该拥有）

授权码意味着您需要将用户的浏览器重定向到授权服务器的授权端点（即至少有可能进行“用户交互”），因为在那里输入了凭据以创建有效会话。如果授权服务器上的会话仍然有效，则重定向到授权服务器以进行第二次授权不应要求用户键入或单击任何内容。但是，如果会话已过期，他们将需要重新输入他们的凭据。

更新：

对我来说，令牌交换对您的用例没有意义。如果您“冒充”，那么您的第二个令牌与第一个令牌具有相同的权限。如果您“委托”您的新令牌具有第一个权限的子集。

委托语义不同于模拟语义，尽管两者密切相关。使用委托语义，委托人 A 仍然有自己与 B 不同的身份，并且它是明确理解，虽然 B 可能已委托其部分对 A 的权利，所采取的任何行动都是由 A 代表 B 采取的。从某种意义上说，A 是 B 的代理人。

你不能委派你没有的权限。

【讨论】：