From the Trenches: Sending and receiving envelopes anonymously
One of the common issues encountered by Developer Support is customers who want to send their envelopes anonymously, without having to send via an individual user’s account, and to have users be able to sign DocuSign envelopes without having a DocuSign account.
Typical reasons for using this model include:
- Staff turnover can make it awkward to deal with envelopes coming back to a user who no longer exists in the organization’s DocuSign account.
- Requiring envelope recipients to sign up for a DocuSign account can increase the perceived complexity of the process, causing recipients to abandon the transaction rather than sign and complete the process. This can reduce participation, adoption, and revenue.
DocuSign recommends a solution combining two techniques:
- Use the JSON Web Token (JWT) Grant flow for authenticating API calls in your integration. This requires setting up a service account under which your integration will authenticate, making it possible to send all envelopes from the same account, to which you can delegate access.
- Use embedded signing in your integration rather than remote signing; combined with the service account, this makes it possible for your users to sign without logging in to DocuSign.
What is JWT ?
To access the DocuSign APIs, your integration must first authenticate itself to DocuSign. DocuSign uses OAuth 2.0 to secure your API requests. Among the OAuth flows DocuSign supports is the JSON Web Token (JWT) Grant flow. JWT Grant is used to grant an access token to service integrations. As the term service integration suggests, a service account is used to make the API calls instead of individual users having to log in to their accounts. (Note: In order to create that service account, the user must have administrator permissions.)
How do I use it? Sending on behalf of users is enabled with the consent process. With this process, end users grant consent for an application to act on their behalf. This allows a service account to impersonate, or act on behalf of, an individual user.
To create a service account, you will need to have an email address created for it (for example, docusign@mycompany.com), then create an administrator account for that email address.
What this means is that when, for instance, a user requests to send an envelope in a remote signing flow, the email will be sent out from the originating user’s account, despite all of the API calls being made by the service account.
Embedded signing
To create a seamless in-app signing experience, you need to combine using a service account with use of embedded signing. For the user experience, they will always see a single view. This will make the sender the same user that authenticated with JWT (the service account), and at the same time, allow for any user to sign without having to sign in.
To see how to implement embedded signing, see Byungjae Chung’s post, Deep dive into the embedded signing recipient view. When you combine both JWT (single user making all the API calls) with embedded signing (single user signing and completing documents), all of the envelopes will be created and managed by a single user.
