> 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

# Authentication

> The TSP Partner program enables Trust Service Providers to integrate their solution directly into the Docusign eSignature experience.

Before your application can make calls to the TSP API, it must authenticate and obtain an access token. This access token proves your app’s identity and authorization. You must submit it with each request to the TSP API. If you're
[delegating the creation of the CMS](/docs/tsp-api/tsp101/cms-service-api) to Docusign, you must provide the same access token you submitted to get the signing information.

TSP authentication uses an extension of the Docusign OAuth framework. This framework requires that you register your TSP as an OAuth client with Docusign.

## Prerequisites

Before you can use the TSP API, you need the following:

1. A Docusign eSignature
   [developer account](/platform/build-integration).

2. An
   [integration key](/platform/configure-app#integration) that identifies your application.

3. A
   [redirect URI](/platform/configure-app#redirect) associated with your integration key. The redirect URI points to a web application managed by the TSP. All signers must log in to this page to authenticate and proceed with the signature process. TSPs can use a localhost address during the development phase then an HTTPS once the integration is live.

Once TSPs get their integration key and redirect URI, they can request the Docusign account server for an access token they will use to authenticate in every call to the TSP API.

## Authentication in the signature process

Once a TSP registers as an OAuth client with Docusign, it authenticates in the signature process as follows:

1. In a Docusign document, a signer selects SIGN and CONTINUE to request signatures from the TSP (see [Getting Started](/docs/tsp-api/tsp101/get-started) for more information on this step).
2.

The Docusign account server sends the following information to the TSP:

* the redirect URI of the TSP (see also **Prerequisites** above)
* a standard OAuth authorization code:

```text
HTTP/1.1 302 Found
        Location: https://client.example.org/cb?
        code=SplxlOBeZQQYbYS6WxSbIA
```

**Code sample 1**: authentication information sent to the TSP

**Note:** the OAuth authorization code expires after 2 minutes.

3. The TSP uses the OAuth authorization code from step 2 to request the creation of a token to access DocuSIgn (see also **Access token request** below).
4. Docusign returns an access token to the TSP.
5. The TSP can now use the access token to call the next TSP API endpoint in the signing flow (see also [Geting Started](/docs/tsp-api/tsp101/get-started). This token is only valid for this transaction. All subsequent requests require a new access token.

## Access token request

The [POST /oauth/token](/platform/auth/reference/obtain-access-token) endpoint contains all the claims needed to complete every request authentication step.

```bash
POST oauth/token HTTP/1.1
Host: account-d.docusign.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic Y2xpZW50SWQ6Y2xpZW50U2VjcmV0
```

```text
grant_type=authorization_code
    &code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
```

The Authorization header follows the OAuth 2.0 Basic authentication schema described in [Section 2.3.1 of the OAuth 2.0 RFC](https://tools.ietf.org/html/rfc6749#section-2.3). It concatenates the client ID, a semicolon, and the client secret. Docusign provides the client ID and client secret when TSPs [configure their applications](/platform/configure-app).

In the above example, the value of the client ID is “clientId” and the value of the client secret is “clientSecret”. Optionally, you can pass this information as the `client_id` and `client_secret` POST parameters.

## Access token response

The response to the access token request contains the following parameters:

* `access_token`: The access token used by the TSP to authenticate with the Docusign APIs.
* `expires_in`: The lifetime of the access token.
* `token_type`: The Bearer, describing the usage of the access token.
* `user_api`: The base URI used for subsequent requests to the TSP REST APIs.

```text
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache{
"access_token": "(access token example removed for document brevity)",
"expires_in": 28800,
"token_type": "Bearer",
"user_api": "https://{server}.docusign.net"
}
```

TSPs must use the returned token in all subsequent requests to authenticate to Docusign. They must also ensure they use the returned base URI in their calls to the TSP API. Note that if you're calling the CMS API, you must use the dedicated [base URL](/docs/tsp-api/tsp101/cms-service-api).