Help me please. There are several users in the docusign account. How to send an envelope from their name? What would an envelope be sent not on behalf of the administrator, but on behalf of the user.
You need to use DocuSign's OAUTH user Application or Service Integration to implement the same. DocuSign Authentication Overview has details about each integration type.
OAuth Authorization Code Grant and OAuth Implicit Grant are suitable only for user applications because it requires an end user to authenticate with DocuSign.
Service Integration Authentication uses JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (RFC 7523) to create an access token. It is ideal for service integrations that do not involve a user agent like a browser or web view control. The result is an access token that represents the application or an impersonated user.
Implementing either User Application or Service Integration, you need to get consent of the user for whom you want to send the envelope and envelope will be sent from that user's account and that user will become the sender of the envelope.
Related
I am trying to integrate Docusign within my web app where users will be able to generate the documents to sign with some information from the web app integrated into Docusign document.
For JWT or Auth Code Grant workflows, Docusign needs the user to sign in to Docusign account to be able to generate an access token.
Now each user cannot really sign into Docusign to generate a document. What's he best way to create Docusign envelops without the end user logging into Docusign account?
If your app's users have DocuSign user accounts, then use Authorization Code grant flow: the user authenticates with DocuSign and then your app uses the user's access_token.
If your app's users do not have DocuSign user accounts (eg the users are your end customers), then:
Create a "system user" in your DocuSign account such as "finance#yourcompany.com"
Authenticate to DocuSign as the system user and grant consent to the application. See this blog post for more.
The above steps are one time only!
Then, when your app is used in production:
When a user starts to use your application, your application uses the JWT grant flow to impersonate the system user.
Via the JWT grant flow, your app now has an access_token that it can use with the DocuSign APIs. Your app can use the access_token to create an envelope, then create a recipient view (embedded signing ceremony)
The app's user can sign via the embedded signing ceremony.
Remember to cache the access_token for the system user. Continue to re-use the access_token until it is about to expire.
See this SO answer for info on caching the access_token
I'm working on an integration with the DocuSign API. I want the users to log in to my app and then initiate the signing process from there. The users must not have a DocuSign account, they should be able to sign without log in to DocuSign. As I understand the JWT Grant flow is the best choice for this scenario by impersonating a system user and create envelopes and recipient view requests for the users who will sign. Please, correct me if I'm doing this wrong.
Many companies who offer electronic signature services also offer authentication services. For example OTP via email, SMS or some other eID. I would like that if the user could authenticate with DocuSign first before accessing my application. I haven't find a service like that at DocuSign. Is there a way to authenticate users without DocuSign accounts for my application with their service?
You first write:
The users must not have a DocuSign account
You later write:
I would like that if the user could authenticate with DocuSign first
before accessing my application
These two statement conflict. You can only authenticate if you have an account.
However, if what you mean is just get an SMS text there are two features you can use:
Send with SMS - sending the SMS as the means of obtaining a signature from user. User doesn't have to have an account with DocuSign.
SMS authentication - envelope is sent via email, SMS is used as a second factor auth. User doesn't have to have an account with DocuSign.
JWT or Auth Code Grant can either be used for the one user/account that does have the ability to send envelopes from DocuSign. Either one would work.
I'm trying to access DocuSign account and app.
How to pass to docusign login without client_id, once login successful it will ask for app and send Integration Keys with Secret Keys of that app in callback?
Step1- User redirect to DocuSign login page with url somethings like this
Response.Redirect(WebUtilities.AddQueryString(Options.AuthorizationEndpoint, new Dictionary<string, string>{
{ "scope", "signature extended" },
{ "response_type", "code" },
{ "state", stateString },
{ "redirect_uri", Options.AppUrl + Options.CallbackPath.ToString() } })
);
and after successful login.
Step2. User should have screen with apps which are in setting and from there after selected any app, it will send Integration key/ Secret key of selected app to call back url. By which I want make calls are per my requirements.
Basic point is user from my web site click on docsign link- it will redirect to login of DocuSign - user will select app on successful login - select app which user want - After selection it will redirect to callback with with IntegrationKey and Secret key.
Hope I am clear now.
Unfortunately your question is not clear. Maybe you can edit it.
To make an API call to DocuSign, you need an access_token. Your application obtains an access_token by using an OAuth authentication flow such as Authorization Code grant or JWT grant.
To receive a webhook notification from DocuSign, you set up your Connect/webhook subscription by using the eSignature Administration tool. You do not need a client_id for this action.
Added
The OP has added to their question:
Basic point is user from my web site click on docsign link- it will redirect to login of DocuSign - user will select app on successful login - select app which user want - After selection it will redirect to callback with with IntegrationKey and Secret key.
I think the question is about authenticating an application's user with DocuSign, then returning to the application.
Answer
The OAuth security standards for the Authorization Code grant require that the user login via the OAuth service provider. In this case account.docusign.com or account-d.docusign.com.
There are two ways to do this:
The application redirects the user's browser to the OAuth service provider. After the first step in the Authorization Code grant flow, the user will be redirected back to the application. The application then makes the call to exchange the authorization code for an access token. The app needs a way to recover its state when the user is redirected back to it. There are several ways to do this.
The application can open a new browser tab to the OAuth service provider. The application continues to run in its original browser tab. The app can programmatically close the tab that it created once the user is authenticated.
Once your app has an access token for DocuSign, it can make API calls to DocuSign. Generally speaking, apps should make API calls to DocuSign on behalf of the user. It is less common for apps to show the DocuSign application to users.
The exception is the DocuSign Signing Ceremony, used for actually signing a document. But signers rarely have a login to DocuSign--they don't need a login to sign.
If you're going to show the DocuSign signing ceremony to your application's users then your application will usually obtain an access token for a system user such as "finance#example.com" (via OAuth JWT impersonation grant) not for the signer since the signer does not have a DocuSign login.
I've developed an invokable Apex method that leverages the DocuSign Apex Toolkit for preparing and sending an envelope via a Salesforce flow.
The only issue I'm having is when it is invoked by a Salesforce user, that has been added as a DocuSign user, but has not yet gone through the OAuth flow to connect Salesforce to DocuSign for their user account.
A workaround is that I have that new user click a standard "Send with DocuSign" button an any record, which then shows the "Before you can use DocuSign, you must grant consent for this application to make requests on your behalf." message and a button to start and complete the OAuth flow. Once this is done I can go back to my flow and it will successfully complete as that user.
Any ideas how I can "pre-authorize" users, or check for authorization as part of the flow (is this data stored in Salesforce), or at least find a way to get to this "Authorize" screen in Salesforce without needing to begin the process of sending an envelope?
Thanks
Matt
Yes, the administrator for the account can grant "blanket" consent, known as administrative consent, for the relevant integration key (client id) and scope(s) needed by your application.
To do so:
The account needs the Admin feature Access Management with SSO You can have this feature enabled for your developer sandbox account by email request to go-live#docusign.com. Contact your DocuSign account manager for adding the feature to a production account.
You need to claim the email domain for your users.
Use the Admin tool's Connected Apps tile to grant administrative consent to your users in the claimed to domain to the application.
The above assumes that you are supplying the integration key to your Apex application.
If you're using an integration key supplied by DocuSign, then you also need to use the Admin consent for external applications API.
If you're using an integration key supplied by DocuSign as part of a DocuSign for Salesforce product, then I would first ensure that the product is enabled for everyone in your account; that may take care of your app's consent issue.
Re: detecting if consent is required
DocuSign responds with a specific consent_required error if consent is needed. So check the error response of your call. See APIError
Within our application we provide a DocuSign integration which uses DocuSign.eSign.dll from DocuSign C# Client.
We currently use the Legacy Header Authentication to authenticate.
One of our customers, would like to enable single sign on using Azure Active Directory. They have set up their account as described on Tutorial: Azure Active Directory integration with DocuSign already (for the DocuSign App).
How do we change our integration to allow Single Sign On using SAML? What API methods do we use? Does the DocuSign C# Client support this?
Legacy Header does not support SSO Authentication. For legacy header to work, users must have a password.
You will either need to grant a Login Policy Exception (to allow them to bypass SSO) to each user that needs to authenticate via the API, or you will need to implement OAuth token authentication.
An example of OAuth token authentication in C# is available on GitHub: https://github.com/docusign/eg-03-csharp-auth-code-grant-core
Once SSO is implemented by your client and has enabled mandatory SSO in their DocuSign configuration, then you should use OAUTH either using Authorization Code Grant-User Application or JSON Web Token Grant-System Integration to generate AccessToken for your Client API user. JSON Web Token Grant is normally used when System Integration is happening in your Integration with DocuSign. In Either way, you need to ask Client API user to provide User Consent to your IntegratorKey, so that your IntegratorKey can generate AccessToken on Client API User's behalf. Obtaining Consent explains how to get User Consent for Either User Application or System Integration. In Providing the consent to your Integrator, Customers will login to DocuSign via their SSO setup, in the same way how they login to DocuSign to access DocuSign WebApp.