DocuSign API - 用户认证后如何获得回调响应？答案

【问题标题】：DocuSign API - How to get callback response after user authentication?DocuSign API - 用户认证后如何获得回调响应？
【发布时间】：2020-02-18 22:08:17
【问题描述】：

我正在尝试实现Implicit Grant REST API of DocuSign。我对用户登录后需要立即执行的操作感到困惑。这是一个独立的本机 Windows 桌面应用程序，而不是 Web 服务或页面。

我打开了一个嵌入式浏览器窗口，导航到正确的 URI 进行登录，并且用户能够成功登录。我还在此应用程序中运行了一个 HTTP 服务器，用于接收回调。事实上，回调确实有效，我确实收到了一个传入的 HTTP GET 命令。但是，此回调响应中没有任何可用的内容。没有特殊的标头、参数、正文，什么都没有。

在尝试 Implicit Grant API 之前，我首先尝试了 JWT Grant 方法，然后才意识到这不是正确的方法。但我的观点是，至少我在回调命令中有一个code 参数。但转而使用隐式授予方法后，此响应为空。

根据文档：

在获得同意后，身份验证服务会验证客户端应用程序是否有效并且可以访问所请求的范围。如果是这样，它将访问令牌重定向到哈希片段中提供的回调 URI。

响应包含以下哈希片段参数：

.......

它甚至显示了一个示例响应：

http://localhost/#access_token=eyJ0eXAi.....9LyiFrUqvdw&expires_in=28800&token_type=bearer&state=a39fh23hnf23

但是，如前所述，我收到的回调响应没有什么值得注意的价值。它本质上只是空的。

我在这里缺少什么？完成身份验证过程并继续实际使用 API 的正确方法是什么？

注意：我使用的是 Delphi，所以 DocuSign 提供的示例都不兼容。

【问题讨论】：

查看我的更新答案

标签： delphi authentication docusignapi indy chromium-embedded

【解决方案1】：

更新答案 当您不将后端服务器作为身份验证流程的一部分时，请使用隐式授权。隐式授权适用于客户端 ID 的秘密/RSA 私钥无法保护的任何时间——应用程序架构中没有安全服务器的任何时间。这包括移动应用程序（因为可以对应用程序进行逆向工程、单页应用程序（React、Angular 等）和桌面/厚客户端应用程序（例如 Delphi 应用程序）。

我在使用 React 编写的 DocuSign 应用程序中使用 Implicit Grant。

在您的情况下，您正在编写一个完全在桌面上运行的“厚客户端应用程序”。

由于 DocuSign 的 OAuth2 隐式授权流程符合标准，因此框架的示例是一个很好的起点，用于与其他 OAuth2 身份提供者进行身份验证。

对于 Delphi，请参阅 Accessing Facebook API 的示例。虽然与 DocuSign 的隐式授权流程不完全相同，但它已经足够接近了。特别要注意，当请求response_type=token 时，Facebook 如何在 URL 片段中返回访问令牌（如 Delphi 示例中所做的那样）。

引自 Facebook authentication docs:

response_type = 令牌。响应数据作为 URL 片段包含并包含访问令牌。 桌面应用程序必须为 response_type 使用此设置。这在客户端处理令牌时最有用。

[强调添加]

底线：使用/修改使用 Facebook 进行身份验证的 Delphi 示例，因为 DocuSign 是相似的。如果你不能让它工作，请向 Delphi 客户服务寻求帮助，参考 Facebook 身份验证示例。

PS 一旦您解决了问题，请提供您自己的答案，其中包括您使用的代码 - 以便将来帮助其他人。谢谢！

【讨论】：

谢谢，我现在才知道出了什么问题。虽然我提供了一个回调 URI，它实际上触发了我的 HTTP 服务器，但它不包括 access_token 参数或任何参数。但是，嵌入式浏览器，在用户登录后，实际上确实导航到我的重定向 URI 以及必要的参数。 callback uri 和 redirect uri 是同一个东西，这真是令人困惑。
发表了答案。

【解决方案2】：

我发现我做错了什么。这是一些混乱和术语混淆。当我说我的回调 URI 确实有效时，这是指它触发了我的 HTTP 服务器在应用程序内进行侦听 - 但没有可用数据。

但是，我实际上需要做的不是在 HTTP 服务器中捕获请求，而是在用户身份验证后捕获嵌入式浏览器导航到的 URI。一旦我在成功登录后嗅探到这个浏览器的 URI，现在我实际上可以看到access_token。

所以callback uri 和redirect uri 是完全相同的东西，但很容易被误解。我对它们有两种不同的定义，其中回调是响应原始调用者，重定向意味着自动从一个页面导航到另一个页面。

现在我很好奇我是否需要一个 HTTP 服务器，或者我是否可以盲目地抛出任何任意重定向 URI（当然是在帐户中注册的）并在嵌入式浏览器导航后获取 URI。

至于为什么我的 HTTP 服务器没有看到这些数据，而嵌入式浏览器却看到了，我无法理解。两边都应该匹配。

仅供参考，我使用的嵌入式浏览器是 Chromium (DCEF3)，HTTP 服务器是 Indy 的TIdHTTPServer 组件。

更新

如 cmets 中所述，HTTP 服务器在设计上不接收 URI 的“书签”部分，因为书签只是客户端的东西。根本没有理由将它发送到服务器。因此安全级别 - 由于该信息将仅由客户端使用，而不是服务器，因此通过 Web 将access_token 发送到服务器是有风险的。因此，它将它保持在客户端浏览器的本地。这就是为什么我在浏览器上看到这些数据，而不是在 HTTP 服务器请求处理程序上。

【讨论】：

我认为您不需要服务器。您只需要管理您的浏览器。它在 url 的片段部分的响应中接收访问令牌。诀窍是您需要在执行操作时捕获该 url/uri。干得好！
@LarryK 我愿意打赌我正在使用的 HTTP 服务器组件（Indy for Delphi）以某种方式忽略了 URI 的“书签”部分，因为“书签”通常只用于客户端 - 我无法想象服务器需要书签的真实情况。所以很可能书签被服务器丢弃了，这就是为什么 HTTP 请求是空的，没有任何可用的。我确实觉得有点奇怪，为什么机制会将其放入书签而不是参数中。
@LarryK 我添加了indy 标签，希望 Indy 开发人员 Remy 可以在这一点上提供一些附加信息。因为当这个 HTTP 服务器接收到一个请求时，除了任何书签信息之外，请求信息包含所有内容 - 当观察“原始”HTTP 命令时，它会显示 URI，包括参数，但没有书签字符串。
书签本身不是 URL 的一部分，因此任何客户端都不应该请求书签。不是服务器丢弃书签，而是服务器一开始就不应该接收书签。
你甚至不需要合法的 URL，只需要当服务器告诉浏览器重定向到它时你可以寻找的唯一的东西（当然，你需要阻止浏览器实际请求它，因为它实际上并不存在）。

【解决方案3】：

隐式授权主要用于移动应用程序，对于桌面应用程序，您需要使用Authorization Code Grant，通过这种方法，您将在 RedirectUrl 中获取代码。另请注意在您的集成密钥配置中选择Authorization Code Grant 单选选项。

【讨论】：

文档确实强调授权代码授予方法适用于服务器/客户端 Web 应用程序，这不是我正在做的。您确定这是桌面应用程序的正确解决方案吗？
我认为桌面应用程序是指 WebApp（基于浏览器），那么你有一个独立的应用程序吗？因为对于授权代码授权，它需要您身边的基于浏览器的应用程序来读取代码。如果您不能让基于浏览器的应用程序从 URL 读取代码，并且您只需要获得一次同意，那么最好是获得 JWT 同意，它会要求最终用户给予一次性同意，并且一旦同意给定那么您的应用程序可以为该用户生成访问令牌。
是的，独立的 Windows 应用程序。它确实有一个用于登录的嵌入式浏览器和 HTTP 功能 - 但在尝试 JWT 时，它更加复杂和困难，特别是在实际生成 JWT 时。我采用了一种更简单的方法，虽然不那么安全，因为这将是一个使用它的小型内部公司应用程序。
有很多库可以帮助您创建 JWT，请在 jwt.io 网站查看不同语言的库。
嗨，Amit，隐式授权适用于客户端 ID 的秘密/RSA 私钥无法保护的任何时间——应用程序架构中没有安全服务器的任何时间。这包括移动应用程序（因为可以对应用程序进行逆向工程，单页应用程序（React、Angular 等）和胖客户端应用程序（例如 Delphi 应用程序）。