如何正確設置DocuSIgn oAuth2進程

Question

我真的很困惑你的API的OAuth2進程。在文檔中它說：「客戶端應用程序應該顯示一個UI提示用戶輸入電子郵件/密碼並負責保留信息保密，而不是在本地保存。「

我的觀點是OAuth2在這裏沒有實現的目的。客戶端應用程序不應該關心用戶的電子郵件和密碼。 DocuSign表示不要在本地存儲密碼！什麼如果任何客戶開發存儲用戶密碼併爲DocuSign用戶創建安全威脅的應用程序？

我已經與幾個API使用OAuth2驗證，這是我第一次遇到不同的流。你能否請賜教我如何實際應用這個，你能舉個例子嗎？

下面是我們的應用程序的工作原理。它連接docusigns用戶，我們將持有他們的access_tokens，我們將用它來代表他們發送自定義信封/小部件。我們不想問使用我們的域名的用戶的電子郵件和密碼。

我不認爲我在正確的軌道上，我有點混淆，請我需要你的幫助。

Answer 1

關鍵問題是，目前的DocuSign REST API OAuth2功能確實不支持單點登錄而不是。

相反，OAuth2功能使您的DocuSign客戶端應用程序不會存儲清晰的用戶名/密碼對，以代表指定用戶使用API​​進行身份驗證。另一方面，「代表他人發送」（SOBO）也使應用程序不會存儲將發送交易（信封）的其他人的用戶名/密碼。相反，您將一個用戶名稱指定爲「身份驗證用戶」。 More info.

所以這一切都取決於你的用例。請記住，API最常用於發送事務進行簽名，而不是簽署文檔。您可以作爲「系統用戶」發送，也可以代表您的帳戶中的其他用戶發送。

要刪除的需要爲您的客戶端應用程序存儲用戶名/密碼，您的應用程序可以：

1. 申請一個用戶名/密碼，從一個人的
2. Obtain an OAuth2 token.
3. 忘記了用戶名/ pw
4. 在隨後的API調用中使用令牌而不是用戶名/ pw對。令牌不會過期，因此可以無限制地存儲和使用它。 （它可以由用戶既可以通過的DocuSign Web界面或通過API明確撤銷。）

對於你的使用情況：

以下是我們的應用程序的工作。它連接DocuSigns的用戶，我們將持有他們的access_tokens，我們將用它來代表他們發送自定義信封/小部件。我們不想問使用我們的域名的用戶的電子郵件和密碼。

聽起來好像您的應用程序應該爲最終用戶所屬的每個帳戶擁有一個「身份驗證用戶」。（您不會說所有的用戶是否都在同一個帳戶中。）通常，DocuSign的每個公司/客戶都有一個用於他們所有用戶的帳戶。但許多DocuSign客戶由於各種原因確實擁有多個賬戶。一個用戶可以屬於多個賬戶。

認證用戶將代表（SOBO）發送最終用戶。在這種情況下，你不需要知道用戶的權重。 （你不會持有他們的OAuth2令牌，也不需要請求他們的密碼。）

但是你確實需要他們的電子郵件（他們在DocuSign中的用戶名）。推測你的應用程序有這個信息。

此外，您需要決定如何在DocuSign內設置發送用戶帳戶。您可以假設該帳戶存在，然後優雅地處理該情況。

或者您可以通過API在賬戶內配置用戶。 Create_user method.

此外，用戶是否會直接登錄到DocuSign？如果是這樣，那麼用戶可能希望用DocuSign實現SSO。 DocuSign SSO使用SAML。

新增

如果您使用SOBO認證用戶的想法，然後想驗證用戶的系統用戶對您的應用程序的（但你需要每個帳戶的DocuSign一個）。系統用戶的憑證通常包含在配置文件中，您仍然可以執行此操作。或者，您可以在安裝時爲系統用戶創建令牌 - 名稱/密碼將由管理員添加。無需向普通用戶詢問密碼。

對於任何用於任何DocuSign 發件人的應用程序，在任何帳戶中，通常您都會有一個將應用程序「添加」到新帳戶的供應步驟。這將是一個管理步驟，由管理員完成。您的sw會指示管理員爲新帳戶創建一個認證用戶，然後輸入該用戶的電子郵件/密碼。

如果您的應用只是從您的應用向任何與您的應用關聯的隨機人員發送簽名請求（或甚至是收到確認請求的消息），請記住簽名是免費的 - 收件人用戶不需要DocuSign帳戶。

如果你的客戶想要「發送」簽名請求（通過你的應用程序）並在他們的賬戶中看到它們，那麼這聽起來像你想爲每個客戶的預配賬戶使用帶有認證用戶的SOBO。請注意0​​。

不使用SOBO您也可以計劃你的應用程序如下：

1. 喬用戶表示對您的應用程序，他有一個帳戶的DocuSign，並希望您的應用程序代爲發送。
2. 你看看你的令牌存儲。如果你有Joe的代幣，你可以使用它。如果你不這樣做，那麼你告訴喬必須讓你的應用程序與他的DocuSign賬戶一起工作。爲此，您需要他一次輸入他的DS電子郵件/密碼。
3. 您使用Joe的存儲令牌發送簽名請求作爲 Joe。

你說得對，這個流程可能會產生信任問題。爲了最大限度地減少您需要查看DocuSign電子郵件/密碼的頻率，我將使用Authenticating User + SOBO。這樣，當您將DocuSign賬戶添加到您的系統時，您只需要詢問一次。

增加了一些更 如果你的客戶，對於他們的DocuSign帳戶稀疏（換句話說，你的客戶通常不具備的DocuSign戶口在普通），那麼我會用簡單的非去-SOBO流量。

爲什麼？更簡單的爲您的客戶。如果他們將成爲DocuSign帳戶中唯一使用您的應用的人，那麼在帳戶級別進行配置步驟幾乎沒有意義。

你說得對，你的一些客戶可能會問：「你爲什麼不使用OAuth2？」答案是DocuSign API尚不支持它。

最終加入

的OAuth2用戶的DocuSign支持的DocuSign REST API中：由於docs說：

資源所有者密碼格蘭特是的DocuSign REST API中唯一支持的OAuth2流程。這允許客戶端應用程序通過爲用戶提供用戶名，密碼和集成者密鑰直接從REST API獲取訪問令牌。獲取訪問令牌後，它將用於API調用，而不是用戶名/密碼/集成商組合鍵。

有關SOBO信息，請參閱docs 1,docs 2，並docs 3。如果您對SOBO有進一步的問題，請打開一個新的StackOverflow問題。