M2M requirements and best practices | Jewelers Mutual

A machine-to-machine client authenticates with the client credentials grant: there is no user present, and the client itself is the caller. This page covers how to get a token, what a receiving API checks, and how to handle rotation and failures. For a tool acting on behalf of a signed-in person instead of a service, use authorization code with PKCE, covered under Login options.

Requesting a token

What the API validates

Every request is checked for:

A valid signature against the tenant JWKS
The expected issuer and audience
An unexpired token
The scopes the specific endpoint requires

Scopes

Scopes are granted per client and are enforced per endpoint. A client should hold only the scopes it uses.

Scope pattern	Grants
`read:*`	Read access to that resource type
`create:*`	Creating new records
`update:*`	Modifying existing records
`delete:*`	Deleting records

Caching tokens

Request a token once, cache it in memory, and refresh it shortly before expiry. Minting a token per request wastes the token endpoint’s rate budget and adds latency to every call.

Rotating secrets

Rotating a client secret invalidates the previous one immediately, so every consumer of that client has to be updated in the same change window.

Troubleshooting

Symptom	Likely cause
`401 Invalid token`	Wrong audience, wrong tenant, or a malformed header
`401 Token expired`	The cached token outlived its lifetime
`403 Missing required scope`	Valid token, but the client lacks the scope
`502`	The API’s own credentials to Auth0 were rejected or Auth0 was unreachable

See Error codes for the full list.