2017-11-13 5 views
0

すべてのルートでは、DocuSignユーザーとして認証されている必要があります。標準的なサービス統合フローでは、ユーザーはdocusignの/oauth/authフローを介してユーザーに指示し、返されたコードを使用して/oauth/tokenでアクセストークンを取得し、/oauth/userinfoでそのトークンを使用してユーザーIDを取得し、JWTで署名して使用できます。DocuSign - 組織の管理者がアプリケーションをあらかじめ承認しているユーザーのユーザーIDを取得する。

DocuSignでは、oauth UIを使用してユーザーの同意を得る代わりに、組織の管理者がアプリケーション内の全員のアプリケーションを事前に承認することができます。 oauthフローを介して組織メンバーを送信する必要はありません。すばらしいです。

/oauth/userinfoルートには、ユーザーIDを与えるルートには、ユーザーを通過させることによって得られるoauthコードが必要なため、この操作を実行すると、アプリケーションがどのユーザーに代わってリクエストを行うことができないのかは不明です。 DocuSignのoauthブラウザUI

具体的には、foo.comのDocuSign組織の管理者が自分のアプリケーションを許可し、[email protected]が自分のアプリケーションの使用を開始すると、[email protected]のユーザーIDでJWTを作成するにはどうすればよいですか?

+0

将来のトークンで再利用するためにこのdocusignユーザIDを保存するのは安全か、ユーザIDが変更された場合には '/ oauth/userinfo'を続ける必要がありますか? – jtmarmon

答えて

0

"[email protected]が自分のアプリケーションの使用を開始する"と言うとき、正確に何を意味していますか?

ケース1:ボブがアプリケーションとやりとりしています。その場合は、ユーザアプリケーションOAuthフロー(Authorization Code Grantなど)を使用してログインできるようにする必要があります。

もしあなたの周りにいないときにあなたのアプリがボブに代わって行動する必要があるならば、JWTグラントで後で使うためにボブのユーザIDを保存します。

ケース2:アプリはバックグラウンドで実行されています(人間とのやりとりなし)。ある時点で、あなたのアプリは彼を偽装してBobのことをする必要があります。あなたが持っているのは彼のメールアドレスだけです。

あなたのアプリがBobとのやりとりをしていない場合は、事前に(Bobのアカウントにある)管理者としてアクセスして、彼のメールからBobのuser_idを検索する必要があります。

この2番目のアカウントは、あなたのアプリの「管理者ユーザーアカウント」になります。アカウントには、ユーザーの情報を参照するための管理者権限が必要です。あなたのアプリがインストールされると、あなたのアプリはこの管理者アカウントにアクセスできます。

Users:list APIコールを使用してください。電子メールアドレスをエンコードすることを忘れないでください。

例:

GET call: /v2/accounts/{accountId}/users?email=larry%2Buser%40foo.com 

日時:user_idの寿命私はUSER_IDのGUIDが与えられたために変更されないことを合理的に確信しているユーザー(DocuSignの上のアカウントのメンバーである誰かを)占めました。私は確認するために確認します。

関連する問題