简介和动机

写一篇关于如何使用自定义SAML身份提供者的一次性密码流来接收用户特定的JSON Web令牌的博客文章的想法是在舒适的圣诞节前夕出现的，当时我正在为2021年即将到来的客户项目准备开发设置。

在为这篇文章做准备之前，让我先声明一下：

如果你对诸如JWT、云计算运行时的授权和身份验证管理（简写为XSUAA）、角色集合等术语完全陌生，我建议你先阅读我同事Jeffrey Groneberg的博客文章，因为它解释了所有这些基本术语和概念。如果没有对这些主题的基本理解，你可能很难阅读和理解这篇高级文章，因为它建立在这些知识的基础上。此外，我还要特别感谢两位伟大的同事。没有沃尔夫冈·希梅尔斯巴赫和尼科莱·本茨，这篇文章是不可能的。感谢你们的想法、贡献和大力支持！

说到这里，让我们跳进这篇文章的需求和场景：

你现在肯定想问自己：为什么一个人需要一个特定于用户的JWT？对于即将到来的客户项目，我想基于分配的用户组设置一个角色集合映射。为了验证JWT所进行的正确的范围分配，超算云，我想对发布的JWT进行解码，并检查所有预期的范围是否都是它的一部分，是否可以用于进一步的授权检查。

上述项目的基础设施和解决方案架构本身并不具体，我甚至会称之为主流。这篇文章的要求可以描述如下：

到目前为止，我相信作为这篇文章的读者，您很可能会同意，这些高层次的要求可以在SAP上下文中针对许多开发（和扩展）场景进行描述。如果您已经使用了上述组件，那么下面的高级体系结构模型对您来说应该不是新的。它显示了自定义身份验证租户与SAP云平台的专用子帐户之间建立的信任。此外，它还表示使用Approuter作为传入请求的入口点，特价云服务器，以及与XSUAA实例进行必要的服务绑定，以便在运行时发出有效的JWT。

默认情况下，Approuter将JWT注入到最终用户发出的传入请求中。这个流本身并没有返回JWT，因为我可以检查令牌携带的信息。然而，这个场景提供了一个框架，以便对我们正在移动的域有一个共同的理解。

虽然可以肯定的是，可以操纵返回JWT的批准者，但是我的目标是从分配给XSUAA实例的认证url中获取令牌。出于测试目的，可以实现一种请求处理程序，将JWT打印出来作为测试的一部分，这样我就可以对其进行解码并读取所有携带的信息。让我们看看如何才能做到这一点。

密码授予将做的把戏，对吗？！

然而，使用自定义IdP而不使用默认SAP ID服务这一部分出乎意料地给我带来了一个挑战，我想总结如下：

JWT确保在应用程序使用的组件之间传输和交换授权相关信息。为了验证基于上述需求3的任务是否正确工作，我打算为一个专用（业务）用户接收一个特定于用户的JWT。为了使用REST客户机接收这样一个令牌，我看到了一些博客文章，还有一些教程解释了如何通过使用密码授权流来实现这一点。

进一步研究通过使用这种流接收用户特定JWT所需的参数，我天真地想："好吧，这正是我需要的。只需提供上下文给定用户的用户名和密码以及一些通用的可用属性（例如clientid、clientsecret、grant类型和token格式），并接收带有所有相关作用域和属性的JWT…

到目前为止还不错，我把所有的值放入Postman中，并期待着发起请求，然后收到JWT。然而，我能说什么：它没有工作。我从认证机构得到的唯一信息是：

好吧，我想，可能是用户的密码错了。所以让我们再试一次…但是不，还是同样的反应。接下来，让我们问问谷歌（还有谁？！）很快，我就看到了一个描述良好的SAP注释，说明如下：

"授权类型"密码支持OpenID Connect（OIDC）身份提供者，而不是SAML身份提供者。默认情况下，SAP ID服务（源=sap.ids)因此它将与SAP用户（例如S-users）一起使用。SAP云平台身份验证服务（IAS）也可以配置为OIDC IdP（源站）=sap.自定义). 不支持第三方身份提供程序。"

好的，根据上面制定的要求-我们连接了一个自定义身份验证租户，它不是默认的租户（SAP ID）。所以这种行为是众所周知的，不是我搞砸的。但是，如果使用密码授权流是不可能的，那么如何获取特定于用户的JWT来验证正确的范围/属性分配呢？？

一次性密码解救

为什么不看看官方云铸造文档解释所有可用的令牌流。除了前面提到的密码授予流之外，还有两种可能接收JWT。首先是授权码授予流，其次是一次性密码流。第一种选择已经在这篇博文中得到了解释，这意味着这篇博文将关注一次性密码流。