Under heavy development
StitchAPI
GuidesAuth

oauth2

OAuth2 client_credentials: fetch, cache, and auto-refresh a token behind the capability boundary.

Use oauth2 when an API authenticates with the OAuth2 client_credentials grant and you want the access token fetched, cached, and refreshed for you — the stitch holds the client id and secret, the caller never sees the token.

Example

import { , ,  } from 'stitchapi';

const  = ({
    : 'https://api.example.com',
    : '/orders',
    : ({
        : 'https://api.example.com/oauth/token',
        : ('CLIENT_ID'),
        : ('CLIENT_SECRET'),
        : 'orders.read',
    }),
});

The first call to orders() POSTs the form-encoded token request, caches the token in the stitch store (TTL from expires_in), and attaches it as Authorization: Bearer …; later calls reuse the cached token until it nears expiry, all behind the capability boundary.

Options

tokenUrl is the client_credentials token endpoint. Pass clientId and clientSecret as secret resolvers — e.g. env('CLIENT_ID') — so the credentials are read at call time and never committed. scope is an optional space-delimited scope string.

The token is cached and auto-refreshed: refreshSkewMs (default 30_000) refreshes it that many milliseconds before expiry, so it is never used mid-flight, and refreshOn (default [401]) lists the statuses that mean the token was rejected and force a fresh fetch plus retry.

Give two stitches the same key plus a shared store and one token serves them all — across stitches and across workers, surviving restarts. See Reference → Auth strategies for every field.

The token lives only in the store and the outgoing Authorization header — the caller, an agent included, never receives it. That is the capability boundary; see Capability, not credential.

See also

On this page