Skip to navigation

Recipient authentication

View as Markdown

You can use recipient authentication to verify a recipient’s identity and help ensure that they are who they claim to be. Docusign provides several optional methods for recipient authentication for both the eSignature API and Docusign SDKs:

You can also include a record of your recipient authentication method in your certificate of completion after embedded signing.

Recipient authentication is also called multi-factor authentication because it enables you to enforce more than one authentication method. For example, making a signature request via email would be one authentication factor, but making a signature request via email that also requires ID verification would be two authentication factors.

It is your responsibility as an envelope sender to determine which recipient authentication methods are needed to secure your documents, but keep in mind that enforcing many authentication methods can make signing documents cumbersome for your recipients. Your integrations should consider what is appropriate for the document(s) being signed. For example, if your recipients are simply acknowledging and signing a license agreement, it may not be necessary to enforce KBA authentication.

All recipient authentication methods except ID verification are enabled in the developer (demo) environment for you to test and develop with, but you may incur an additional charge in the Docusign production environment. Check your Docusign plan or contact your account manager to determine if there are any additional costs in production.

Docusign supports authentication and signing workflows that enable customers to meet the requirements of the Food and Drug Administration (FDA) 21 CFR Part 11 regulation. See CFR Part 11 accounts for more information.

Access code authentication

An access code is an alphanumeric phrase that you can set on an envelope before it is sent to recipients. Each recipient is prompted to enter the access code before they are able to open the documents contained in the envelope. Access code requirements are customizable in the Security Settings page in eSignature Admin.

See How to require access code authentication for a recipient for details on how to implement access code authentication.

Phone authentication (call or SMS)

Phone authentication requires the recipient to verify access to their phone number by receiving a call or a text message giving them an authentication code that they must enter to gain access to the documents contained in the envelope. Recipients may choose whether to receive the authentication code via call or via text.

Phone authentication may not be enabled for some older developer accounts. If you cannot choose to use phone authentication for your account, contact support to request access.

When using phone authentication or a customized identity verification configuration that is based on phone authentication, you must also provide the corresponding workflow ID value along with the API call to authenticate with the identity provider. You can obtain the full list of your workflow IDs using the IdentityVerifications:list endpoint.

See How to require phone authentication for a recipient for details on how to implement phone authentication and specify your workflow ID.

Using SMS authentication may incur additional costs due to sending additional SMS messages.

Knowledge-based authentication (KBA)

Knowledge-based authentication requires recipients to answer detailed questions about themselves, based on data available in public records (such as their current and former addresses). The Docusign eSignature KBA feature uses an identity verification service from LexisNexis Risk Solutions that validates user identities in real time.

See How to require knowledge-based authentication (KBA) for a recipient for details on how to implement KBA authentication.

ID verification (IDV)

eSignature REST API 2.1 only

ID verification is a recipient authentication technology that verifies the identity of recipients based on government photo IDs (such as a driver’s license or passport) and electronic IDs. IDV verifies authenticity via visible security features, watermarks, and machine-readable barcodes. The best way to understand how this works is to view this video:

ID verification is available to develop API integrations in developer (demo) accounts, but is not enabled by default. To enable IDV in your developer and/or production accounts, contact your Docusign Account Manager or Partner Account Manager.

After IDV is enabled on your account (either developer or production), it is configured as a workflow on the account. Each account that has IDV enabled is automatically assigned a unique workflow ID, which needs to be supplied along with the API call to authenticate with the identity provider. You can obtain the full list of your workflow IDs using the IdentityVerifications:list endpoint.

See How to require ID verification (IDV) for a recipient, for details on how to implement IDV, including retrieving a workflow ID for your account and specifying your workflow ID. You can also review the IdentityVerifications resource.

Create a record of recipient authentication after embedded signing

You can use the authenticationMethod parameter of an EnvelopeViews:createRecipient method call to record the type of recipient authentication that you used in an embedded signing scenario.

When you set the authenticationMethod parameter, you are saying that your app has already authenticated the recipient in the specified manner. After embedded signing has concluded, your certificate of completion will record the specified recipient authentication type.

  • In embedded signing, your app should have already authenticated the signer using out-of-band methods (although in-Docusign methods can be added as well).
  • The authenticationInstant, assertionId, and securityDomain EnvelopeViews:createRecipient parameters are optional. You can use them to record security details about the embedded signing agreement in the certificate of completion, enabling you to relate them back to your internal records to prove validity and non-repudiation.

For example, if you authenticate your recipient’s identity based on their driver’s license ID, you could choose an authenticationMethod parameter value of PaperDocuments. After signing is completed, the certificate of completion would show that the signer was authenticated using their physical paper ID documents. In this example, the assertionId and authenticationInstant parameters could be used to reference a record in your systems that provides additional evidence.

You can use the following authenticationMethod values:

  • Biometric
  • Email
  • HTTPBasicAuth
  • Kerberos
  • KnowledgeBasedAuth
  • None
  • PaperDocuments
  • Password
  • RSASecureID
  • SingleSignOn_CASiteminder
  • SingleSignOn_InfoCard
  • SingleSignOn_MicrosoftActiveDirectory
  • SingleSignOn_Other
  • SingleSignOn_Passport
  • SingleSignOn_SAML
  • Smartcard
  • SSLMutualAuth
  • X509Certificate

Next steps