我正在创建一个需要使用我的Docusign帐户的服务集成。我首先查看身份验证信息，然后找到Legacy Header页面。建议不要将其用于服务集成
Legacy Header身份验证以前建议用于服务集成。 DocuSign建议使用服务集成身份验证构建新的服务集成。
所以我决定去那个陈述<{p>>的Service Integration Authentication page
在应用程序冒充用户之前，应用程序必须直接从用户或其帐户管理员处获得同意。
然后在授予同意部分中说明
用户同意可以从授权代码授予或隐式授权开始。
但是，Authorization Code Grant和Implicit Grant页面都位于页面顶部
此授权不适用于服务集成。
那我应该不使用这些补助金吗？如果我不这样做，则会让我重新使用Legacy Header身份验证。我没有问题，但为什么建议不要使用它，然后建议不要使用替代品？我错过了什么吗？
答案 0 :(得分：2)
对不起，服务集成的文档不明确。我们将努力改进它。
TL; DR - 观看我的screencast，我专注于这个问题。
这是独家新闻：
如果您正在编写应用程序供您自己的组织使用，则建议将JWT流用于Service Integrations。如果您是ISV（如果您将软件销售给DocuSign客户），那么目前还有其他问题需要考虑。
使用JWT流并模拟某人或指定的“系统用户” （通常的情况）然后你的应用程序需要许可才能这样做。如果您启用了组织管理，您的组织管理员可以主动授予您的应用授权，以模拟您组织中的任何人。
您还可以让每个人单独授予权限。例如，您在DocuSign中创建了一个名为“HR Dept”的用户。然后您登录为“人力资源部门”并授予该应用程序模拟“人力资源部门”的权限。
用户首次使用时会向应用授予权限。但用户不“使用”服务集成！ （正如您通过文档发现的那样。）
这就是诀窍：在DocuSign中将应用程序设置为Auth Code Grant应用程序（设置重定向URI）和JWT流程应用程序（创建公钥/私钥对）。为方便起见，请将重定向URI设置为现有站点。例如，https://www.docusign.com
然后，每个将被模拟的用户，告诉他们在浏览器中输入特定的URL。该URL是OAuth Auth Code Grant流程的第一站。它是
${AUTHENTICATION_URL}/oauth/auth?response_type=code&scope=${encoded_scopes}&client_id=${CLIENT_ID}&redirect_uri=${REGISTERED_REDIRECT_URI}`
# AUTHENTICATION_URL = https://account-d.docusign.com (demo)
# AUTHENTICATION_URL = https://account.docusign.com (production)
# CLIENT_ID = your integration key
# encoded_scopes = signature%20impersonation
# REGISTERED_REDIRECT_URI = https://www.docusign.com (or whatever
# you registered)
当用户输入上述网址时，DocuSign会要求他们登录，然后让他们向您的应用授予权限（范围）。
然后你可以运行你的JWT流程（不需要用户），你就是黄金。