🪪Sign in with DocSign (OIDC)

What it does

Discovery doc at /.well-known/openid-configuration, JWKS at /.well-known/jwks.json, RS256-signed id_tokens. Partners register a client at /settings/oauth-clients; they get a dso_ client_id and a one-time client_secret. The authorize endpoint enforces PKCE-S256, exact-match redirect URIs, and a per-client scope allowlist.

How it works

1. 1

   Partner registers an OAuth client and chooses scopes (openid required, plus email / profile / identity / offline_access / signing:proof).

2. 2

   Partner sends the user to /api/oauth/authorize with code_challenge.

3. 3

   User logs in (if not already), reviews scopes, and clicks Allow.

4. 4

   DocSign redirects back to the partner's redirect_uri with a one-time code.

5. 5

   Partner exchanges code + PKCE verifier at /api/oauth/token for an access_token + id_token (+ refresh_token if offline_access was granted).

Why it matters

• ✓Drop-in compatibility with any off-the-shelf OIDC client library (oidc-client-ts, openid-client, etc).
• ✓The signing:proof scope adds a verifiable Ed25519 signature to the id_token — opt-in cryptographic strength.
• ✓Refresh tokens rotate; replay of a rotated refresh token revokes the whole grant.

Verify an id_token against JWKS

Copy-paste starting point for integrating this feature.

import { jwtVerify, createRemoteJWKSet } from "jose";

const jwks = createRemoteJWKSet(
  new URL("https://docsign.example.com/.well-known/jwks.json"),
);
const { payload } = await jwtVerify(idToken, jwks, { audience: CLIENT_ID });
// payload.sub is stable per user; payload.email is the verified address.
// If you also requested signing:proof, payload.signing_proof is a
// verifiable Ed25519 signature you can re-check with @noble/ed25519.

Related features