> You are reading the Docusign Developer Documentation. For clean Markdown of any page, append .md to the page URL. > > Documentation indexes by section: > - APIs and SDKs: https://docusign.docs.buildwithfern.com/docs/llms.txt > - Platform 101: https://docusign.docs.buildwithfern.com/platform/llms.txt > - Extension Apps: https://docusign.docs.buildwithfern.com/extension-apps/llms.txt > - Docusign CLI: https://docusign.docs.buildwithfern.com/docusign-cli/llms.txt > > Authentication (OAuth, JWT Grant, M2M): https://docusign.docs.buildwithfern.com/platform/auth > Webhooks and Connect: https://docusign.docs.buildwithfern.com/platform/webhooks > > OpenAPI specifications: https://docusign.docs.buildwithfern.com/openapi.json > MCP server: https://docusign.docs.buildwithfern.com/_mcp/server # Recipient authentication > Learn about the methods that recipients can authenticate their identities during the signing ceremony, & how your app can implement these authentication methods. 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: * [Access code authentication](/docs/esign-rest-api/esign101/concepts/recipients/auth#access-code-authentication) * [Phone authentication (call or SMS)](/docs/esign-rest-api/esign101/concepts/recipients/auth#phone-authentication-call-or-sms) * [Knowledge-based authentication (KBA)](/docs/esign-rest-api/esign101/concepts/recipients/auth#knowledge-based-authentication-kba) * [ID verification (IDV)](/docs/esign-rest-api/esign101/concepts/recipients/auth#id-verification-idv) You can also [include a record of your recipient authentication method](/docs/esign-rest-api/esign101/concepts/recipients/auth#create-a-record-of-recipient-authentication-after-embedded-signing) in your certificate of completion after [embedded signing](/docs/esign-rest-api/esign101/concepts/embedding). 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. > **Note** > > 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](/docs/esign-rest-api/esign101/concepts/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](https://support.docusign.com/s/document-item?bundleId=pik1583277475390\&topicId=yuz1583277329300.html) in eSignature Admin. See [How to require access code authentication for a recipient](/docs/esign-rest-api/how-to/require-access-code-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. > **Note** > > Phone authentication may not be enabled for some older developer accounts. If you cannot choose to use phone authentication for your account, [contact support](https://support.docusign.com/s/contactSupport) 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](/docs/esign-rest-api/reference/accounts/identityverifications/list) endpoint. See [How to require phone authentication for a recipient](/docs/esign-rest-api/how-to/phone-auth) for details on how to implement phone authentication and specify your workflow ID. > **Note** > > 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](/docs/esign-rest-api/how-to/knowledge-based-authentication) for details on how to implement KBA authentication. ## ID verification (IDV) eSignature REST API 2.1 only [ID verification](/docs/esign-rest-api/how-to/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: > **Note** > > 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](/docs/esign-rest-api/reference/accounts/identityverifications/list) endpoint. See [How to require ID verification (IDV) for a recipient](/docs/esign-rest-api/how-to/id-verification), 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](/docs/esign-rest-api/reference/accounts/identityverifications) resource. ## Create a record of recipient authentication after embedded signing You can use the `authenticationMethod` parameter of an [EnvelopeViews:createRecipient](/docs/esign-rest-api/reference/envelopes/envelopeviews/createrecipient) method call to record the type of recipient authentication that you used in an [embedded signing](/docs/esign-rest-api/esign101/concepts/embedding) 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](/docs/esign-rest-api/reference/envelopes/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 * See [How to require access code authentication for a recipient](/docs/esign-rest-api/how-to/require-access-code-recipient). * See [How to require phone authentication for a recipient](/docs/esign-rest-api/how-to/phone-auth). * See [How to require knowledge-based authentication (KBA) for a recipient](/docs/esign-rest-api/how-to/knowledge-based-authentication). * See [How to require ID verification (IDV) for a recipient](/docs/esign-rest-api/how-to/id-verification). * See the MyAPICalls sample app [Phone Authentication](https://myapicalls.sampleapps.docusign.com/scenario/5) scenario, which walks you through sequence of API calls that retrieve a list of identity verification workflows and create an envelope that requires phone authentication.