Machine to machine authentication for services and jobs
Machine to machine authentication is how a service, a scheduled job or a backend script proves its identity to an API when no user is present. The standard way is the OAuth client credentials grant, where the service exchanges its own credentials for a short-lived access token. The Skycloak Platform is built to issue those tokens, with private_key_jwt and DPoP planned for its first release.
How the client credentials grant works
In the client credentials grant, each service is registered as an OAuth client with its own identifier and credentials. When it needs to call an API, it sends those credentials to the token endpoint and gets back an access token, which it attaches to each request. The API checks the token's signature, issuer, audience and scopes before it does any work, and it never needs to see the service's credentials.
Because no user signs in, this flow has no browser, no redirect and no consent screen. Each service should have its own client rather than sharing one, so you can tell which service made a call and revoke one without affecting the others. Scopes on the token limit what each service may do, for example reading invoices but not changing them.
Replacing shared secrets with private_key_jwt and DPoP
The simplest client credential is a shared secret, a long random string that both the service and the authorization server know. It works, but the secret has to be copied into configuration, it can leak through logs or code repositories, and anyone who holds it can request tokens. With private_key_jwt, the service instead signs a short assertion with a private key that never leaves it, and the server checks that assertion against the matching public key.
DPoP, short for demonstrating proof of possession, goes a step further by binding the access token to a key held by the service. Each request carries a fresh proof signed with that key, so a token copied from a log or intercepted on the way cannot be used by anyone else. Both private_key_jwt and DPoP are planned for the Platform's first release, along with pushed authorization requests (PAR) for flows where a user is present.
Short-lived tokens, scopes and an audit trail
Access tokens for services are best kept short-lived, measured in minutes rather than days, because a short lifetime limits how long a leaked token stays useful. A service can simply request a new token when the old one expires, so short lifetimes cost it very little. Together with narrow scopes and a separate client per service, this keeps the effect of any single leak small and easy to trace.
On the Skycloak Platform, the clients your services use are managed through one public management API, which the console, a CLI and an MCP server all use as well. API keys for that API carry read and write scopes per resource, every write is audited, and rate limits apply per key and per workspace. Creating a client, changing its scopes or rotating its credentials therefore leaves a record of who did it and when.
Frequently asked questions
Is the client credentials grant the same as an API key?
No. An API key is usually a long-lived string sent with every request, while the client credentials grant exchanges the service's credentials for a short-lived access token with scopes. The API then only ever sees tokens that expire, and the credentials themselves go only to the token endpoint.
Do machine to machine clients work with standard OAuth libraries?
Yes. The client credentials grant is part of standard OAuth, so any OAuth client library that supports it can request tokens from the Platform. private_key_jwt and DPoP are open standards too, and both are planned for the Platform's first release.
See the Skycloak Platform for yourself
Book a demo and we will walk you through the Platform with your own sign-in flows in mind.