---
title: "Authenticating Signers"
slug: "authenticating-signers"
description: "Enhance online transaction security with OneSpan Sign's flexible recipient-authentication options, including SMS, Email, and Knowledge-Based Authentication."
updated: 2026-04-20T14:31:03Z
published: 2026-04-20T14:31:03Z
canonical: "docs.onespan.com/authenticating-signers"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.onespan.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authenticating Signers

For information on SMS authentication, see [SMS Phone Number Validation](/v1/docs/sms-validation).

## Java SDK

To download the full code sample see our [Code Share](https://community.onespan.com/documentation/onespan-sign/codeshare/authenticating-signers-java-sdk/) site.

To add an extra layer of security to your online transactions, OneSpan Sign offers robust and flexible recipient-authentication options. Specifically, you can select various ways of verifying the identity of the recipient of an invitation to a transaction before they are permitted to access the transaction's documents.

General Authentication refers to tools built into OneSpan Sign that enable you to verify the identity of the recipient through SMS, Email, or a custom Question and Answer format.

Knowledge-Based Authentication (KBA) relies on a third-party KBA provider to perform the authentication. That provider is [LexisNexis](https://www.lexisnexis.com/en-us/gateway.page). .

KBA questions are generated dynamically, based on information in a signer's personal credit report.

KBA authentication can be used in conjunction with any one of the General authentication methods above.

To enable *Knowledge-Based Authentication*, please contact our [Support Team](https://www.onespan.com/support).

### Using General Authentication

The code below illustrates how to edit the signer block for each general authentication method. If you need a comparison with basic document-object creation, or if this is your first time creating a package with the Java SDK, see this [Creating a Transaction](https://docs.onespan.com/v1/docs/creating-and-sending-a-transaction#java-sdk).

```java
.withSigner(
    newSignerWithEmail("first.signer@email.com")
        .withFirstName("First")
        .withLastName("Signer")
        .challengedWithQuestions(
            ChallengeBuilder.firstQuestion("What's your favorite sport?")
                .answer("soccer")
                .secondQuestion("What music instrument do you play?")
                .answer("drums")
        )
)
.withSigner(
    newSignerWithEmail("second.signer@example.com")
        .withFirstName("Second")
        .withLastName("Signer")
        .withSmsSentTo("1234567890")
)
```

#### Manually sending an SMS code

A new SMS code is generated and sent each time a signer clicks the email link. If for any reason you need to manually send a new SMS code, you can do so by using PackageService and passing the PackageId and Signer objects as parameters. The following code will do this:

```java
eslClient.getPackageService().sendSmsToSigner(
    packageId,
    retrievedPackage.getSigner(email1)
);
```

### Using KBA

You can also authenticate a signer with KBA. You can also edit the signer block to implement KBA. The following code will do this:

```java
.withSigner(newSignerWithEmail(email1)
                        .withFirstName(FIRST_NAME)
                        .withLastName(LAST_NAME)
                        .challengedWithKnowledgeBasedAuthentication(newSignerInformationForLexisNexis()
                                .withFirstName(FIRST_NAME)
                                .withLastName(LAST_NAME)
                                .withFlatOrApartmentNumber(FLAT_OR_APARTMENT_NUMBER)
                                .withHouseName(HOUSE_NAME)
                                .withHouseNumber(HOUSE_NUMBER)
                                .withCity(CITY)
                                .withZip(ZIP)
                                .withState(STATE)
                                .withSocialSecurityNumber(SOCIAL_SECURITY_NUMBER)
                                .withDateOfBirth(DATE_OF_BIRTH)))
```

### Results

After running your code, if a transaction is sent with signer authentication enabled, your signers will be required to validate their identity using the method specified in the transaction.

With *Knowledge Based Authentication*, the signer's identity is verified by asking them a series of questions about their personal credit report.

## .NET SDK

To download the full code sample see our [Code Share](https://community.onespan.com/documentation/onespan-sign/codeshare/authenticating-signers-net-sdk/) site.

To add an extra layer of security to your online transactions, OneSpan Sign offers robust and flexible recipient-authentication options. Specifically, you can select various ways of verifying the identity of the recipient of an invitation to a transaction before they are permitted to access the transaction's documents.

General Authentication refers to tools built into OneSpan Sign that enable you to verify the identity of the recipient through SMS, Email, or a custom Question and Answer format.

Knowledge-Based Authentication (KBA) relies on a third-party KBA provider to perform the authentication. That provider is [LexisNexis](https://www.lexisnexis.com/en-us/gateway.page). .

KBA questions are generated dynamically, based on information in a signer's personal credit report.

KBA authentication can be used in conjunction with any one of the General authentication methods above.

To enable *Knowledge-Based Authentication*, please contact our [Support Team](https://www.onespan.com/support).

#### 

### SMS Phone Number Validation

When using SMS authentication, the OneSpan Sign evaluates the phone number provided in the request payload to determine how it should be interpreted and validated. Understanding this behavior helps ensure that phone numbers are correctly processed and that authentication messages are delivered successfully.

If a phone number contains **exactly 10 digits with no leading + sign**, OneSpan Sign automatically assumes that the signer is located in **North America**. In this case, the country code `1` is appended to the number before it is stored or returned in the response payload.

For example:

5551234567 becomes 15551234567

This behavior applies only when the number is 10 digits and does **not** include an explicit country code.

Some countries also use 10‑digit phone numbers by default. If the signer is located outside North America but their number still consists of 10 digits, you must include a leading `+` in the request payload. This ensures the system does not incorrectly assume the number belongs to the North American numbering plan.

For example:

+5551234567

#### Phone Number Preprocessing and E.164 Formatting Guidelines

In addition to the SMS Phone Number validation described above, OneSpan Sign also uses a preprocessing workflow that sanitizes and standardizes all inputs into the internationally recognized E.164 format. This ensures that numbers are stored and returned in a consistent structure across all APIs.

E.164 is the global standard for international telephone numbering as defined by the [International Telecommunication Union (ITU)](https://en.wikipedia.org/wiki/International_Telecommunication_Union). It defines how numbers should be structured so they can be recognized and routed anywhere in the world. An E.164 phone number includes:

- A maximum of 15 digits
- Digits only (0–9)
- No spaces, hyphens, parentheses, or other separators
- A leading `+` to indicate an international number

OneSpan recommends that you **submit phone numbers directly in E.164 format**. However, our system also accepts several alternative user‑entered formats and standardizes them automatically. This means that we accept various formatted inputs and convert them to the correct E.164 structure during preprocessing.

For example, we accept inputs such as:

(+32) 0470123456

Even though this example includes parentheses and a leading zero after the country code, our preprocessing removes the non-digit characters and the leading zero, and returns it in E.164 format:

+32470123456

The use of a leading zero is accepted by most European countries, but may not be accepted by all. The use of a leading zero is not accepted for North American numbers.

The `Get Package` API will always return the phone number in this standardized format.

+ [Country Code] [National Destination Code] [Subscriber Number]

Here are some examples of E.164 numbers:

| Country | Example (E.164) | Explanation |
| --- | --- | --- |
| United States/Canada | +14155552671 | +1 = country code |
| United Kingdom | +442079460123 | +44 = UK |
| France | +33142278186 | +33 = France |
| India | +919876543210 | +91 = India |

| Correct Number Format | Incorrect Number Format |
| --- | --- |
| +14155552671 | (415) 555-2671 +1 415 555 2671 0044 20 7946 0123 |

### Using General Authentication

The code below illustrates how to edit the signer block for each general authentication method. If you need a comparison with basic document-object creation, or if this is your first time creating a package with the Java SDK, see this [Creating a Transaction](https://docs.onespan.com/v1/docs/creating-and-sending-a-transaction#net-sdk).

```csharp
.WithSigner(
    SignerBuilder.NewSignerWithEmail("first.signer@example.com")
        .WithFirstName("First")
        .WithLastName("Signer")
        .ChallengedWithQuestions(
            ChallengeBuilder.FirstQuestion("What's your favorite sport?")
                .Answer("golf")
                .SecondQuestion("What music instrument do you play?")
                .Answer("drums")
        )
)
.WithSigner(
    SignerBuilder.NewSignerWithEmail("second.signer@example.com")
        .WithFirstName("Second")
        .WithLastName("Signer")
        .WithSMSSentTo("1234567890")
)
```

#### Manually sending an SMS code

A new SMS code is generated and sent each time a signer clicks the email link. If for any reason you need to manually send a new SMS code, you can do so by using PackageService and passing the PackageId and Signer objects as parameters. The following code will do this:

```csharp
eslClient.PackageService.SendSmsToSigner(
    packageId,
    retrievedPackage.GetSigner(email1)
);
```

### Using KBA

You can also authenticate a signer with KBA. You can also edit the signer block to implement KBA. The following code will do this:

```csharp
.WithSigner(
    SignerBuilder.NewSignerWithEmail(email1)
        .WithFirstName(FIRST_NAME)
        .WithLastName(LAST_NAME)
        .WithCustomId(signerId)
        .ChallengedWithKnowledgeBasedAuthentication(
            SignerInformationForLexisNexisBuilder.NewSignerInformationForLexisNexis()
                .WithFirstName(FIRST_NAME)
                .WithLastName(LAST_NAME)
                .WithFlatOrApartmentNumber(FLAT_OR_APARTMENT_NUMBER)
                .WithHouseName(HOUSE_NAME)
                .WithHouseNumber(HOUSE_NUMBER)
                .WithCity(CITY)
                .WithState(STATE)
                .WithZip(ZIP)
                .WithSocialSecurityNumber(SOCIAL_SECURITY_NUMBER)
                .WithDateOfBirth(DATE_OF_BIRTH)
                .Build()
        )
)
 .WithDateOfBirth(DATE_OF_BIRTH)
                                        .Build()))
```

### Results

After running your code, if a transaction is sent with signer authentication enabled, your signers will be required to validate their identity using the method specified in the transaction.

With *Knowledge Based Authentication*, the signer's identity is verified by asking them a series of questions about their personal credit report.

## REST API

To download the full code sample see our [Code Share](https://community.onespan.com/documentation/onespan-sign/codeshare/authenticating-signers-rest-api/) site.

To add an extra layer of security to your online transactions, OneSpan Sign offers robust and flexible recipient-authentication options. Specifically, you can select various ways of verifying the identity of the recipient of an invitation to a transaction before they are permitted to access the transaction's documents.

General Authentication refers to tools built into OneSpan Sign that enable you to verify the identity of the recipient through SMS, Email, or a custom Question and Answer format.

Knowledge-Based Authentication (KBA) relies on a third-party KBA provider to perform the authentication. That provider is [LexisNexis](https://www.lexisnexis.com/en-us/gateway.page). .

KBA questions are generated dynamically, based on information in a signer's personal credit report.

KBA authentication can be used in conjunction with any one of the General authentication methods above.

To enable *Knowledge-Based Authentication*, please contact our [Support Team](https://www.onespan.com/support).

#### 

### SMS Phone Number Validation

When using SMS authentication, the OneSpan Sign evaluates the phone number provided in the request payload to determine how it should be interpreted and validated. Understanding this behavior helps ensure that phone numbers are correctly processed and that authentication messages are delivered successfully.

If a phone number contains **exactly 10 digits with no leading + sign**, OneSpan Sign automatically assumes that the signer is located in **North America**. In this case, the country code `1` is appended to the number before it is stored or returned in the response payload.

For example:

5551234567 becomes 15551234567

This behavior applies only when the number is 10 digits and does **not** include an explicit country code.

Some countries also use 10‑digit phone numbers by default. If the signer is located outside North America but their number still consists of 10 digits, you must include a leading `+` in the request payload. This ensures the system does not incorrectly assume the number belongs to the North American numbering plan.

For example:

+5551234567

#### Phone Number Preprocessing and E.164 Formatting Guidelines

In addition to the SMS Phone Number validation described above, OneSpan Sign also uses a preprocessing workflow that sanitizes and standardizes all inputs into the internationally recognized E.164 format. This ensures that numbers are stored and returned in a consistent structure across all APIs.

E.164 is the global standard for international telephone numbering as defined by the [International Telecommunication Union (ITU)](https://en.wikipedia.org/wiki/International_Telecommunication_Union). It defines how numbers should be structured so they can be recognized and routed anywhere in the world. An E.164 phone number includes:

- A maximum of 15 digits
- Digits only (0–9)
- No spaces, hyphens, parentheses, or other separators
- A leading `+` to indicate an international number

OneSpan recommends that you **submit phone numbers directly in E.164 format**. However, our system also accepts several alternative user‑entered formats and standardizes them automatically. This means that we accept various formatted inputs and convert them to the correct E.164 structure during preprocessing.

For example, we accept inputs such as:

(+32) 0470123456

Even though this example includes parentheses and a leading zero after the country code, our preprocessing removes the non-digit characters and the leading zero, and returns it in E.164 format:

+32470123456

The use of a leading zero is accepted by most European countries, but may not be accepted by all. The use of a leading zero is not accepted for North American numbers.

The `Get Package` API will always return the phone number in this standardized format.

+ [Country Code] [National Destination Code] [Subscriber Number]

Here are some examples of E.164 numbers:

| Country | Example (E.164) | Explanation |
| --- | --- | --- |
| United States/Canada | +14155552671 | +1 = country code |
| United Kingdom | +442079460123 | +44 = UK |
| France | +33142278186 | +33 = France |
| India | +919876543210 | +91 = India |

| Correct Number Format | Incorrect Number Format |
| --- | --- |
| +14155552671 | (415) 555-2671 +1 415 555 2671 0044 20 7946 0123 |

### Using General Authentication

The code below illustrates how to edit the *auth* object for each authentication method. If you need a comparison with basic document-object creation, or if this is your first time creating a package with the Java SDK, see this [Creating a Transaction](https://docs.onespan.com/v1/docs/creating-and-sending-a-transaction#java-rest).

#### HTTP Request

```http
POST /api/packages
```

#### HTTP Headers

```http
Accept: application/json
Content-Type: application/jsonAuthorization: 
Basic api_key
```

#### Request Payload

```json
 {
  "roles": [
    {
      "type": "SIGNER",
      "index": 0,
      "signers": [
        {
          "auth": {
            "scheme": "CHALLENGE",
            "challenges": [
              {
                "answer": "golf",
                "question": "What's your favorite sport?",
                "maskInput": false
              }
            ]
          },
          "email": "mail22@example.com",
          "firstName": "Patty",
          "lastName": "Galant"
        }
      ],
      "name": "Signer1"
    },
    {
      "type": "SIGNER",
      "index": 0,
      "signers": [
        {
          "auth": {
            "scheme": "SMS",
            "challenges": [
              { "answer": null, "question": "+15515584587", "maskInput": false }
            ]
          },
          "email": "mail11@example.com",
          "firstName": "John",
          "lastName": "Smith"
        }
      ],
      "name": "Signer2"
    }
  ],
  "status": "DRAFT",
  "type": "PACKAGE",
  "name": "Signer Authentication Example"
}
```

For a complete description of each field, see the Request Payload section below.

#### **Response Payload**

```json
{
  "id": "9sKhW-h-qS9m6Ho3zRv3n2a-rkI="
}
```

#### Manually sending an SMS code

A new SMS code is generated and sent each time a signer clicks the email link. If for any reason you need to manually send a new SMS code, the following code will do this:

#### HTTP Request

```http
POST /api/packages/{packageId}/roles/{roleId}/sms_notification
```

#### HTTP Headers

```http
Accept: application/json
Content-Type: application/json
Authorization: Basic api_key
```

### Using KBA

You can also authenticate a signer with KBA. You can also edit the signer block to implement KBA. The following code will do this:

```json
 {
  "id": "Signer1",
  "index": 0,
  "type": "SIGNER",
  "signers": [
    {
      "email": "john.smith@mailinator.com",
      "firstName": "John",
      "language": "en",
      "lastName": "Smith",
      "id": "Signer1",
      "auth": {
        "scheme": "NONE",
        "idvWorkflow": null,
        "challenges": []
      },
      "knowledgeBasedAuthentication": {
        "signerInformationForLexisNexis": {
          "city": "CALERA",
          "dateOfBirth": "1973-02-02T00:00:00Z",
          "firstName": "John",
          "lastName": "Smith",
          "socialSecurityNumber": "666110007",
          "houseName": "Decarie",
          "flatOrApartmentNumber": "1234",
          "houseNumber": "5678",
          "zip": "35040",
          "state": "AL"
        }
      }
    }
  ],
  "name": "Signer1"
}
```

### Results

After running your code, if a transaction is sent with signer authentication enabled, your signers will be required to validate their identity using the method specified in the transaction.

With *Knowledge Based Authentication*, the signer's identity is verified by asking them a series of questions about their personal credit report.

### **Request Payload Table**

| Property | Type | Editable | Required | Default | Sample Values |
| --- | --- | --- | --- | --- | --- |
| status | string | Yes | No | DRAFT | DRAFT / SENT / COMPLETED / ARCHIVED / DECLINED / OPTED_OUT / EXPIRED |
| type | string | Yes | No | PACKAGE | PACKAGE / TEMPLATE / LAYOUT |
| name | string | Yes | No | n/a | Signer Authentication Example |
| roles |  |  |  |  |  |
| type | string | Yes | No | SIGNER | SIGNER / SENDER |
| index | index | Yes | No | 0 | 0 / 1 / 2 ... |
| name | string | Yes | No | n/a | Signer1 |
| signers |  |  |  |  |  |
| email | string | Yes | No | n/a | mail22@example.com |
| firstName | string | Yes | No | n/a | Patty |
| lastName | string | Yes | No | n/a | Galant |
| auth |  |  |  |  |  |
| scheme | string | Yes | No | n/a | CHALLENGE / SMS |
| challenges |  |  |  |  |  |
| answer | string | Yes | No | n/a | golf |
| question | string | Yes | No | n/a | What's your favorite sport? |
|  |  |  |  |  | / +15515584587 |
| maskInput | boolean | Yes | No | false | true / false |

## APEX SDK

To download the full code sample see our [Code Share](https://community.onespan.com/documentation/onespan-sign/codeshare/authenticating-signers-apex-sdk/) site.

To add an extra layer of security to your online transactions, OneSpan Sign offers robust and flexible recipient-authentication options. Specifically, you can select various ways of verifying the identity of the recipient of an invitation to a transaction before they are permitted to access the transaction's documents.

General Authentication refers to tools built into OneSpan Sign that enable you to verify the identity of the recipient through SMS, Email, or a custom Question and Answer format.

Knowledge-Based Authentication (KBA) relies on a third-party KBA provider to perform the authentication. That provider is [LexisNexis](https://www.lexisnexis.com/en-us/gateway.page). .

KBA questions are generated dynamically, based on information in a signer's personal credit report.

KBA authentication can be used in conjunction with any one of the General authentication methods above.

To enable *Knowledge-Based Authentication*, please contact our [Support Team](https://www.onespan.com/support).

### SMS Phone Number Validation

When using SMS authentication, the OneSpan Sign evaluates the phone number provided in the request payload to determine how it should be interpreted and validated. Understanding this behavior helps ensure that phone numbers are correctly processed and that authentication messages are delivered successfully.

If a phone number contains **exactly 10 digits with no leading + sign**, OneSpan Sign automatically assumes that the signer is located in **North America**. In this case, the country code `1` is appended to the number before it is stored or returned in the response payload.

For example:

5551234567 becomes 15551234567

This behavior applies only when the number is 10 digits and does **not** include an explicit country code.

Some countries also use 10‑digit phone numbers by default. If the signer is located outside North America but their number still consists of 10 digits, you must include a leading `+` in the request payload. This ensures the system does not incorrectly assume the number belongs to the North American numbering plan.

For example:

+5551234567

#### Phone Number Preprocessing and E.164 Formatting Guidelines

In addition to the SMS Phone Number validation described above, OneSpan Sign also uses a preprocessing workflow that sanitizes and standardizes all inputs into the internationally recognized E.164 format. This ensures that numbers are stored and returned in a consistent structure across all APIs.

E.164 is the global standard for international telephone numbering as defined by the [International Telecommunication Union (ITU)](https://en.wikipedia.org/wiki/International_Telecommunication_Union). It defines how numbers should be structured so they can be recognized and routed anywhere in the world. An E.164 phone number includes:

- A maximum of 15 digits
- Digits only (0–9)
- No spaces, hyphens, parentheses, or other separators
- A leading `+` to indicate an international number

OneSpan recommends that you **submit phone numbers directly in E.164 format**. However, our system also accepts several alternative user‑entered formats and standardizes them automatically. This means that we accept various formatted inputs and convert them to the correct E.164 structure during preprocessing.

For example, we accept inputs such as:

(+32) 0470123456

Even though this example includes parentheses and a leading zero after the country code, our preprocessing removes the non-digit characters and the leading zero, and returns it in E.164 format:

+32470123456

The use of a leading zero is accepted by most European countries, but may not be accepted by all. The use of a leading zero is not accepted for North American numbers.

The `Get Package` API will always return the phone number in this standardized format.

+ [Country Code] [National Destination Code] [Subscriber Number]

Here are some examples of E.164 numbers:

| Country | Example (E.164) | Explanation |
| --- | --- | --- |
| United States/Canada | +14155552671 | +1 = country code |
| United Kingdom | +442079460123 | +44 = UK |
| France | +33142278186 | +33 = France |
| India | +919876543210 | +91 = India |

| Correct Number Format | Incorrect Number Format |
| --- | --- |
| +14155552671 | (415) 555-2671 +1 415 555 2671 0044 20 7946 0123 |

### Using General Authentication

The code below shows you how to create a Role Object for each signer authentication method. If you need a comparison with basic document-object creation, or if this is your first time creating a package with the Apex SDK, see this [guide](https://docs.onespan.com/v1/docs/creating-and-sending-a-transaction#apex-sdk).

```plaintext
 ESignLiveAPIObjects.Role role = new ESignLiveAPIObjects.Role();
```

```plaintext
ESignLiveAPIObjects.AuthChallenge firstChallenge = new ESignLiveAPIObjects.AuthChallenge(
    firstQuestionAnswer, 
    false, 
    firstQuestion
); // Question & Answer

ESignLiveAPIObjects.AuthChallenge secondChallenge = new ESignLiveAPIObjects.AuthChallenge(
    secondQuestionAnswer, 
    false, 
    secondQuestion
); // Question & Answer

ESignLiveAPIObjects.AuthChallenge smsAuthentication = new ESignLiveAPIObjects.AuthChallenge(
    null, 
    false, 
    phoneNumber
); // SMS
```

#### Manually sending an SMS code

A new SMS code is generated and sent each time a signer clicks the email link. If for any reason you need to manually send a new SMS code, you can do so using the following function encapsulated in the Code Share:

```plaintext
 public void sendSmsToSigner(String packageId, String roleId)
```

### Using KBA

You can also authenticate a signer with KBA. You can use the two encapsulated functions below to create a role, and add it to an existing transaction. The two functions are used separately for Equifax USA and Equifax CA:

```plaintext
public void createRoleWithKBA_EquifaxUSA(
    String packageId,
    String roleId,
    String firstName,
    String lastName,
    String email,
    String streetAddress,
    String city,
    String zip,
    String state,
    Integer timeAtAddress,
    String driversLicenseNumber,
    String dateOfBirth,
    String socialSecurityNumber,
    String homePhoneNumber
)

public void createRoleWithKBA_EquifaxCA(
    String packageId,
    String roleId,
    String firstName,
    String lastName,
    String email,
    String streetAddress,
    String city,
    String zip,
    String state,
    Integer timeAtAddress,
    String driversLicenseNumber,
    String dateOfBirth,
    String socialSecurityNumber,
    String homePhoneNumber
)
```

### Results

After running your code, if a transaction is sent with signer authentication enabled, your signers will be required to validate their identity using the method specified in the transaction.

With *Knowledge Based Authentication*, the signer's identity is verified by asking them a series of questions about their personal credit report.