OAuth Walkthrough

OAuth allows you to perform actions on behalf of other users after they grant you the authorization to do so. For example, you could send signature requests on behalf of your users. This page lays out the basic steps to build your own OAuth flow and send calls on behalf of your users using an access token.

App Setup

Create an app

Before you can do anything with OAuth, you’ll need to create an app and configure it to use OAuth.

App Settings

When creating an app, you’ll need to provide the following information:

Choosing Scopes

Scopes control the level of access granted to an access token. On your app settings page, choose the scopes that fit your particular use case for OAuth. Scopes are split up by billing model and organized around specific groups of actions (like signature requests). You can read more about them in the Access Scopes section of the OAuth Overview page.

App Approval

Dropbox Sign requires production approval for apps using OAuth. That means your app can’t be authorized or added by other users until it is approved for production. When you feel your app is ready to go live, please follow the app approval process to request approval for your app.

Checking for a Dropbox Sign account

A user needs to authorize your app before an access token can be issued and used on their behalf. Dropbox Sign has an OAuth flow for two scenarios:

1. Authorization code flow — user has an existing Dropbox Sign account.
2. Account creation flow — user is new to Dropbox Sign.

We recommend checking whether a user has a Dropbox Sign account (/account/verify) before selecting the corresponding flow:

1
{
2
  "email_address": "some_user@dropboxsign.com"
3
}

Response if the user has an account:

1
{
2
  "account": {
3
    "account_id": "f57db65d3f933b5316d398057a36176831431a90",
4
    "email_address": "user@example.com"
5
  }
6
}

Response if the user does not have an account:

1
{
2
  "error": {
3
    "error_msg": "Account not found",
4
    "error_name": "not_found"
5
  }
6
}

Authorization Code Flow

Dropbox Sign recommends the authorization code flow for generate access tokens for users that already have a Dropbox Sign account. Sometimes called the “3 legged OAuth flow”, this approach consists of three distinct steps:

1. Obtaining consent from the user generates an authorization code.
2. The authorization code is exchanged for an access token using a token endpoint.
3. The access token is used to send API calls on behalf of the user according to the authorization they granted.

Obtaining user authorization

Existing Dropbox Sign users can authorize your app by navigating to your app’s authorization url. This url can be constructed manually in your code or you can copy it from the app details modal of your API settings page:

For example (line breaks for readability only):

1
https://app.hellosign.com/oauth/authorize
2
  ?response_type=code
3
  &client_id=cc91c61d00f8bb2ece1428035716b
4
  &state=900e06e2
5
  &redirect_uri=YOUR_APP_REDIRECT_URI

• The state parameter is used for security and must match throughout the flow for a given user. It can be set to the value of your choice (preferably something random). You should verify it matches the expected value before processing parameters on an OAuth callback.
• If redirect_uri is provided provided in the Authorization URL, the value must match the OAuth Callback URL specified in the API app settings. If redirect_uri is not provided, users will be redirected to the Default OAuth Callback URL.

Users grant their authorization on an OAuth consent page that shows them the name of your app and the level of access (scopes) being requested. They can choose to Accept or Deny the authorization request. Both actions will redirect the user back to your OAuth callback URL. If the user clicked Accept and authorized your app then the URL will contain a code and state parameter. However, if they clicked Deny, then only the state parameter will be present and the OAuth flow cannot be completed.

Generating an Access Token

Once the user has given their consent and you’ve retrieved the authorization code from the url, you’ll need to exchange it for an access token by calling the token endpoint. Make a POST request to /oauth/token with the following parameters:

Example

1
{
2
"state": "900e06e2",
3
"code": "1b0d28d90c86c141",
4
"grant_type": "authorization_code",
5
"client_id": "cc91c61d00f8bb2ece1428035716b",
6
"client_secret": "1d14434088507ffa390e6f5528465"
7
}

1
{
2
  "access_token": "1a2b3c4d5e6f7g8h9i0j",
3
  "token_type": "Bearer",
4
  "expires_in": 3600,
5
  "refresh_token": "9i8h7g6f5e4d3c2b1a0",
6
  "account_id": "f57db65d3f933b5316d398057a36176831431a90"
7
}

At the end of a successful Authorization Code flow, you’ll receive a payload that contains an access_token, which can be used to send API calls on behalf of the user that authorized your app. You can see how to use it in the Making API Calls with Access Tokens section below.

Account Creation Flow

When a user without a Dropbox Sign account visits your authorization url, they’ll need to sign up from that page before they can authorize your app. It’s possible to do that, but we also offer an approach. You can create the users Dropbox Sign account and get the access token at the same time. However, the access token will not work until the user has confirmed their account and authorized your app.

Create account

The first step is calling /account/create and passing your API app’s client_id and client_secret.

Example

$
curl 'https://api.hellosign.com/v3/account/create' \
>
    -u '0ca97430f712bd3898e782000d4387c60c464155afbdb49d1fddda27c7443b98:' \
>
    -F 'email_address=jill@example.com' \
>
    -F 'client_id=cc91c61d00f8bb2ece1428035716b' \
>
    -F 'client_secret=1d14434088507ffa390e6f5528465'

User confirms account

The user is sent an email from Dropbox Sign with a hyperlink to confirm their account activation. Once the user accesses Dropbox Sign, they’re prompted to authorize your Dropbox Sign app.

Once the new user has approved your app, the access_token can be used to call the Dropbox Sign API on their behalf. The refresh_token should also be saved and used once the access token expires.

Making API Calls With Access Tokens

Now that you have an access_token, you can make API calls on behalf of other users. When making API calls, you’ll need to pass the access token by setting the HTTP header Authorization: Bearer <oauth2-access-token>.

Example

$
curl 'https://api.hellosign.com/v3/signature_request/list' \
>
    -H 'Authorization: Bearer NWNiOTMxOGFkOGVjMDhhNTAxZN2NkNjgxMjMwOWJiYTEzZTBmZGUzMjMThhMzYyMzc='

Signature Request with Access Token

For this example, let’s send a non-embedded signature request (/signature_request/send) and replace the basic auth with an access token.

Example

$
curl 'https://api.hellosign.com/v3/signature_request/send' \
>
    -H 'Authorization: Bearer NWNiOTMxOGFkOGVjMDhhNTAxZN2NkNjgxMjMwOWJiYTEzZTBmZGUzMjMThhMzYyMzc=' \
>
    -F 'title=NDA with Acme Co.' \
>
    -F 'subject=The NDA we talked about' \
>
    -F 'message=Please sign this NDA and then we can discuss more. Let me know if you have any questions.' \
>
    -F 'signers[0][email_address]=jack@example.com' \
>
    -F 'signers[0][name]=Jack' \
>
    -F 'signers[0][order]=0' \
>
    -F 'signers[1][email_address]=jill@example.com' \
>
    -F 'signers[1][name]=Jill' \
>
    -F 'signers[1][order]=1' \
>
    -F 'cc_email_addresses[0]=lawyer@example.com' \
>
    -F 'cc_email_addresses[1]=lawyer2@example.com' \
>
    -F 'file[0]=@NDA.pdf' \
>
    -F 'file[1]=@AppendixA.pdf' \
>
    -F 'test_mode=1'

Refreshing an Access Token

Access tokens are only valid for a given period of time (typically one hour) for security reasons. Whenever acquiring a new access token, the expires_in parameter specifies the time (in seconds) before it expires.

You can use the refresh_token to generate a new access_token for a user that has previously authorized your app without prompting them to complete another OAuth flow. This creates a smoother experience for users of your app, but only works as long as they have not revoked authorization to your app and the access scopes have not been changed.

Send a POST request to /oauth/token?refresh with the following parameters:

Example

1
{
2
  "grant_type": "refresh_token",
3
  "refresh_token": "hNTI2MTFmM2VmZDQxZTZjOWRmZmFjZmVmMGMyNGFjMzI2MGI5YzgzNmE3"
4
}

1
{
2
  "access_token": "1a2b3c4d5e6f7g8h9i0j",
3
  "token_type": "Bearer",
4
  "expires_in": 3600,
5
  "refresh_token": "9i8h7g6f5e4d3c2b1a0",
6
  "account_id": "f57db65d3f933b5316d398057a36176831431a90"
7
}

More Information

Here are a few links to read up on related topics and get a better understanding of our API.