Machine-to-machine.
No user, no problem.
Backends, worker queues, cron jobs, webhook receivers, partner integrations — anything that needs a token without a human in the loop. Synq ships the OIDC client_credentials grant with brand-scoped audiences, scope-gated authorization, and an SDK that caches and refreshes tokens for you.
One audit trail across every actor
Most teams roll a separate static API-key system for backend-to -backend calls. That means a second authentication surface to secure, a second rotation story, and a second audit log that does not line up with the user one. Synq runs every actor — humans, agents, backends — through the same OIDC issuer. Tokens have the same shape, audit logs share the same schema, and the `azp` claim tells you exactly which client is calling.
Issue, verify, done
Issue an access token with @synqid/js (which caches and refreshes), or with a raw curl. Verify on the receiving backend the same way you verify any Synq-issued token.
// @synqid/js handles caching and refresh automatically
import { createSynqClient } from '@synqid/js'
const synq = await createSynqClient({
issuer: 'https://api.synq.id',
clientId: process.env.M2M_CLIENT_ID!,
clientSecret: process.env.M2M_CLIENT_SECRET!,
})
// Get an access token for the worker — cached + auto-refreshed
const token = await synq.getM2MToken({
scope: 'webhooks:replay audit:read',
})
const r = await fetch('https://api.acme.com/webhooks/replay', {
method: 'POST',
headers: { Authorization: `Bearer ${token.access_token}` },
})Get it live
One App registration. No redirect URI. Done in two minutes.
Register an M2M App
In the Dashboard, create an App of type M2M. Synq issues a client ID and client secret. M2M apps are confidential, so the secret stays on your server.Allow the client_credentials grant
Under Allowed grants, tick `client_credentials`. M2M apps never use auth code or refresh token, so leave the rest unticked.Pick the scopes the worker is allowed to request
List exactly the scopes this backend should be able to ask for — Synq enforces the list as a hard ceiling. A worker that only replays webhooks should not have permission to read audit logs.Store the secret in your secret manager
Vault, AWS Secrets Manager, GCP Secret Manager, Doppler — wherever your team already stores production secrets. The Synq SDK reads them via env vars.Issue tokens from your backend
Use @synqid/js (cached + auto-refreshed) or hit /oauth2/token directly. Tokens are RS256-signed and verify with any JWT library against Synq’s JWKS.
How M2M auth compares
Most platforms ship client_credentials. The differences are in whether M2M and user auth share one issuer and one audit log.
| Feature | Clerk | WorkOS | Auth0 | Synq |
|---|---|---|---|---|
| client_credentials grant shipped | ||||
| Same OIDC issuer as user auth | ||||
| Brand-scoped custom scopes per worker | Limited | |||
| SDK caches + refreshes M2M tokens | ||||
| Audit log unified across user + M2M actors | ||||
| Available on every plan tier |
Pair it with
OpenID Connect
M2M is one OIDC grant of several. See the full issuer page for the rest.
Device flow
When the agent needs a user’s consent, device flow is the right grant. M2M is for actions taken on the worker’s own behalf.
User auth that pairs with M2M for the same backend — one audit trail, two actor types.
Common questions
One auth plane, every actor.
Users, agents, backends — all through the same OIDC issuer, all with the same audit log, all verifiable with the same library.
