OAuth 2.0

**OAuth 2.0 grant types used in e-signing**

• **Authorization Code Grant** — User logs in via a browser, grants permission, and your app receives an authorization code to exchange for tokens. Best for applications where users interact directly.

• **JWT (JSON Web Token) Grant** — Your application uses a private key to generate a JWT, which is exchanged for an access token. No user interaction required. Best for server-to-server integrations and automated workflows.

• **Implicit Grant** — Deprecated. Previously used for single-page applications.

**OAuth 2.0 vs API keys**

Simpler e-signature APIs (like Signbee) use API keys for authentication — a single Bearer token in the Authorization header. This is simpler to implement but provides less granular access control.

DocuSign requires OAuth 2.0 for all API access (legacy authentication was deprecated). This means developers must implement token refresh logic, handle token expiration, and manage the OAuth flow — adding significant integration complexity.

**DocuSign's OAuth migration**

DocuSign deprecated legacy authentication (X-DocuSign-Authentication header) in favour of OAuth 2.0. Existing integrations must migrate to either JWT Grant (for automated/server apps) or Authorization Code Grant (for interactive apps). This migration is a common pain point for developers.

**Token management**

OAuth access tokens expire (typically after 1 hour). Your application must handle token refresh automatically — storing the refresh token securely, requesting new access tokens before expiration, and retrying failed requests after token refresh.