这是对实时流录制内容的可搜索描述，特别是"带qmacro的SAP开发人员实践"系列中的"Ep.58–深入了解oauth2.0forcfapi"。视频录制中有直接指向特定亮点的链接。有关其他剧集的注释链接，请参阅该系列博客文章的"捕捉重播"部分。

该剧集于3月20日星期五直播，长度约为60分钟。视频流录制可以在YouTube上看到。

简介：在上一集中，我们将介绍"客户端凭据"授权类型如何与API集线器和CF工作流API一起工作。现在是时候让我们更深入地挖掘和研究其他流动了。系好安全带！

00:01:00直播开始

00:03:00切换到主场景，展示了OAuth 2.0的一些关键文档，具体描述了OAuth 2.0的四种授权类型："授权码"、"客户端凭据"、"资源所有者密码"和"隐式"。考虑到目前为止我们对OAuth所做的工作，我们记得上周我们使用了"客户机凭据"授予类型（或"流"）。

00:07:40早些时候，回到Ep.51中，我们使用了"资源所有者密码"授予类型，我们将很快看到，这是非常有争议的！

00:08:15现在我们已经建立了不同的补助金类型（或者我们认为是这样），我们简单地看一下OAuth2.0官方网站（疯狂的想法，有哪些云服务器，但是嘿）并注意到一些有趣的事情。这里也列出了四种补助金类型，在"最常见"下…但它们不是相同的四种！

二者相同，具体为"授权码"和"客户凭证"。我们将发现，这些确实非常常见，并且在许多情况下使用。但是另外两个是不同的。第一个是"设备代码"，在我看来，云指，它更像是一个边缘用例流，用于"无浏览器或输入受限的设备"。第二个更有趣。这是"刷新令牌"，我突然将其称为"侧流"，即与"授权码"流相关，在这里可以刷新访问令牌。

00:09:40进一步向下滚动，出乎意料的是，我们看到我们已经列出的其他两种授予类型（从关键页面），"Implicit"和"[Resource Owner]Password"列在"Legacy"标题下！再仔细研究一下，我看到了一份来自Internet工程任务组（IETF，确保互联网络正常工作的标准机构之一）"OAuth 2.0安全最佳当前实践"的权威性文件，特别是第3.4节"资源所有者密码凭据授予"，其中明确地指出，此流必须不能使用。有充分的理由，在文件中解释。此外，也不应使用"隐式"流。

00:11:45我们现在将深入了解"授权码"授权类型，它与"客户凭证"授权类型一起是最常见的；当涉及到人时，前者是相关的。

00:12:40描述了我们在上一集中中断的位置，物联网是什么意思，包括工作流服务的一个实例，已经部署了两个工作流定义–orderprocess，它与我参与的一些其他活动相关，以及simpleworkflow，我们将用于这些实验。它只是一个开始然后立即结束的定义。

00:14:15注意，当您将工作流定义部署为MTA模块时，会为您生成一个服务密钥。这是在其他服务密钥消失的情况下，因为实际上，它们应该被视为可能短暂的，或者至少是可删除的。

00:15:00现在移动到终端（是的，#要探索的未来寄存器）。我已经用我今天使用的这个临时测试用户登录到CF端点并进行了身份验证，查看服务实例列表，我们可以在那里看到工作流服务实例。到目前为止还不错。

00:16:10我们还可以查看我们在web界面中看到的服务密钥摘要，例如：

00:16:40抓取SimpleWorkflow工作流凭据服务密钥的服务密钥详细信息，以便我们以后可以通过编程深入了解这些详细信息：

我们现在必须编辑它，以消除cf在执行这个请求时，命令抛出（cf是一个很好的命令行工具，但我确实认为它在可用性方面缺乏一定的技巧，不幸的是，cf curl方法，使用完全不同的API和心理模型，并不是一个很好的解决方法）。

在编辑时，我们来看看下面的一些细节文件：

我们现在必须编辑它，以消除cf命令在执行这个请求时发出的噪音（cf是一个很好的命令行工具，但我没有）当谈到可用性时，它缺乏一定的技巧，不幸的是，cfcurl方法，使用完全不同的API，因此使用心智模型，并不是一个好方法很好的解决方法）。

在编辑时，我们看一下文件中的一些细节：

endpoints.workflow\u rest\u url是资源服务器的基本URL（在本例中是工作流API端点）uaa.clientid要在流中使用的客户端IDuaa.clientsecret客户端是流中要使用的客户端机密uaa.url是授权服务器的基础URL（用于请求令牌等）

00:18:50简要介绍我们在上一集中创建的skv函数的更新版本，这次允许我在不同的JSON文件上使用它。现在的定义是这样的：

在这里，我可以得到uaa.url来自keys文件的值如下：