我们考虑使用带有ID令牌的OpenID Connect来验证我们的公共API。
以下是我们想要涵盖的使用场景：
- Web UI(单页，客户端JavaScript应用程序)
- 交互式会话中使用的命令行界面(CLI)
- CLI以非交互方式使用，例如在CI/CD管道中
- 在非交互式会话中执行的其他API调用
(1)和(2)的想法是使用OIDC隐式授予类型，这样用户就可以在我们的OpenID Connect身份提供程序中进行交互身份验证(用户名/密码)，并允许RP(依赖方、客户端)访问用户身份。然后，身份提供者将向RP颁发一个短时间的ID令牌、一个刷新令牌和(可选？)一个访问令牌。
对于(3)和(4)，交互式身份验证是不可能的。相反，我们希望向用户颁发令牌，允许他们代表他们访问我们的API。这些令牌应该是长寿命的，只有当它们在系统中被删除时才会失效。
尽管如此，我们还是希望使用JWT，就像身份提供者发布的ID令牌一样，作为内部所有API请求的身份信息载体。
我的问题是：
- 这是否可以完全使用OpenIDConnect隐式授予类型颁发的令牌之一来完成
- 访问令牌是否可以以长期有效的方式(没有过期，只能通过从系统中删除而无效)发布，然后由客户端根据ID令牌进行交换
- 或者刷新令牌正是用于此目的的东西吗
- 或者我们必须在OpenID Connect之外解决这个问题？这就留下了一个问题：如何根据身份详细信息(JWT)解决API请求中的不透明令牌，以便在我们的API/服务中使用
如果使用隐式流(对于场景1和场景2)，则不能使用刷新令牌。您需要客户端凭据(客户端ID和机密)来请求刷新令牌。在隐式流中，我们不存储任何客户端凭据。
当客户端是公共客户端(SPA等)时，将客户端机密存储在其中是不安全的。因此，公共客户端通常使用隐式流。隐式流不支持刷新令牌。一些OIDC库实现了静默令牌续订/刷新功能，以避免缺少刷新令牌。但该模型有一些局限性(您需要与IDP进行活动会话，才能在没有任何中断的情况下进行续订)
TL；DR->如果客户端是公共客户端，则使用隐式流(不需要客户端机密即可从IDP获取访问令牌)。隐式流不支持刷新令牌。
这是否可以完全使用OpenID Connect隐式授予类型颁发的令牌之一来完成？
不可能使用具有隐式流的刷新令牌。授权代码流支持刷新令牌，但不能与SPA客户端一起使用。因此，您需要OAuth 2.0/OIDC流的组合。
访问令牌是否可以以长寿命(无过期，仅通过从系统中删除而无效)的方式发布，然后由客户端根据ID令牌进行交换？
这是两件不同的事情：
- "通过从系统中删除"无效">：我们讨论的是自包含代币与参考代币
自包含令牌：这些令牌包含验证其真实性所需的所有信息，例如发行人详细信息、有效性等。客户端不需要对STS进行反向通道调用来确认真实性。这些令牌有时很难撤销，并且在令牌中指定的持续时间内有效。
引用令牌：引用令牌通常是不透明的令牌，其中包含类似GUID的标识符，没有其他详细信息。为了验证这些令牌的真实性，客户端需要对STS进行反向通道调用。一个主要优点是可以通过删除STS DB中相应的标识符来轻松地撤销它。
-
"由客户端针对
ID令牌Refresh令牌进行交换">-我假设您指的是Refresh令牌，而不是ID令牌。我们为此使用刷新令牌
或者刷新令牌正是用于此目的的东西吗？
是。参考以上评论
或者我们必须在OpenID Connect之外解决这个问题吗？这就留下了一个问题：如何根据身份详细信息(JWT)解决API请求中的不透明令牌，以便在我们的API/服务中使用？
如果使用不透明令牌，OIDC/OAuth 2.0有几个端点(如UserInfo)来获取有关用户的进一步信息。您还可以使用Introspection端点来了解令牌的有效性。
(场景3和4) ：我不确定你打算如何使用它-但对于任何非交互式客户端(它是自己行动的，而不是代表用户)，你应该使用客户端凭据流。
如果客户端希望代表用户进行操作，则应为用户启用一种批准此行为的方式。
我建议任何对OpenID Connect(OIDC)感兴趣的人研究OAuth2规范。由于OIDC是在OAuth2上构建的，因此它继承了许多基本特性。
首先要注意的是隐式流不返回刷新令牌。
隐式授予类型用于获取访问令牌(它不支持发布刷新令牌)，并针对已知操作特定重定向URI 的公共客户端进行了优化
如果你想依赖刷新令牌，那么你必须考虑这个事实。
这是否可以完全使用OpenID Connect隐式授予类型发布的令牌之一来完成
这取决于设计和确切的要求。但您确实可以在Id令牌之上构建身份验证，并将访问令牌用于API调用。若要验证访问令牌，您可以使用API端点的内省端点。
访问令牌是否可以以长期(无到期，仅通过从系统中删除而无效)的方式发布，然后由客户端根据ID令牌进行交换
这可能取决于身份提供程序公开的配置。但根据规范，对于使用隐式流的客户端来说，不应该这样做。仅仅是出于安全原因。这与隐式流不返回刷新令牌的原因完全相同。另一方面，刷新令牌可以使用更长的时间。例如，谷歌的刷新令牌永远不会过期(参考8953983)。
或者刷新令牌正是用于此目的的东西吗
如前所述，刷新令牌可以是长寿命的。并且可以将其交换为新的访问令牌。刷新令牌的id令牌的返回将取决于身份提供程序的实现。例如，Azure AD确实为刷新令牌响应返回ID令牌。但除此之外，身份提供者还可以提供用户信息端点。一篇好文章可以从这个链接找到
或者我们必须在OpenID Connect之外解决这个问题？这就留下了一个问题：如何根据身份详细信息(JWT)解决API请求中的不透明令牌，以便在我们的API/服务中使用
ID令牌确实有助于从客户端对最终用户进行身份验证。但当涉及到从API端点验证用户时，您可以考虑使用内省端点或用户信息端点。但请注意，有些身份提供者不提供内省端点。在撰写本文时，Azure AD没有公开一个(参考-43378748)，但提供了一个用户信息端点。