Machine-to-machine auth (client credentials)
One service proves its own identity to another and gets limited API access, with no human login or user account involved.
What it is
Machine-to-machine auth lets a program obtain access without redirecting a human through a login screen. In the OAuth 2.0 client credentials grant, a confidential client authenticates to the token endpoint and receives a scoped access token representing the application itself, not a user.
Reach for it when a worker, scheduled job, or backend service calls another API under its own authority. It gives you short-lived tokens, scopes, and central revocation where a static API key would otherwise live for years. The downstream API must make application-level permissions explicit because there is no user permission to inherit.
A client secret is still a secret. Never put this flow in browser or mobile code, where anyone can extract it. Give each workload its own client, narrow the audience and scopes, rotate credentials, and cache access tokens only until shortly before expiry. If the system needs to act for a particular person, client credentials is the wrong grant.
Ask AI for it
Implement OAuth 2.0 client credentials for this service integration. POST grant_type=client_credentials, the assigned client_id and client_secret, the exact audience, and the minimum scopes to the Auth0 token endpoint over TLS. Cache the returned access token in server memory until 60 seconds before expires_in, then request a new one; do not request or store a refresh token. On the receiving API, verify the JWT signature against the issuer's JWKS, then validate iss, aud, exp, and scopes before serving the request. Keep the secret in the deployment secret manager, issue a separate client per workload and environment, and never ship either credential to browser code.