Tokens and credentials
Machine identity
Credentials issued to a service, workload or agent rather than to a person.
What Machine identity means
Machine identity is authentication for things that are not users — services, jobs, workloads and increasingly autonomous agents. It shares a protocol surface with user authentication and almost none of its assumptions: there is no browser, no consent screen, no password reset, and nobody to notice something is wrong.
How it works
The traditional approach is a long-lived API key in an environment variable. It is simple, it works, and it has no expiry, no rotation story, no way to tell which of five services is using it, and it appears in logs, crash dumps and screenshots.
The standards-based approach issues short-lived tokens through the client credentials grant, sender-constrains them with DPoP so a copy is not usable elsewhere, and narrows them at each hop with token exchange. Rotation becomes automatic because the token expires in minutes and the workload re-authenticates.
Agents sharpen the requirement. An agent that calls many services on a user's behalf needs an identity distinct from that user's, credentials scoped to the specific action, and an audit trail that records which agent acted and under whose authority. A shared service account provides none of that.
The mistake people actually make
Reusing one service account across many workloads. Nothing in the audit log distinguishes them, the credential cannot be rotated without coordinating every consumer, and revoking it during an incident takes down systems nobody knew depended on it.
In Authreads
How this applies here
Machine and agent identity is available today, using DPoP (RFC 9449) and Token Exchange (RFC 8693).
Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.
Guides that go deeper
- DPoP implementation guide: sender-constrained tokens without mTLS
- OAuth token exchange (RFC 8693) for delegation and impersonation
- Service-to-service authentication with the client credentials grant
- Designing identity for a multi-tenant SaaS product
- Identity for marketplaces: buyers, sellers and the platform
- Identity for API and developer platforms
Related terms
DPoP
Demonstrating Proof of Possession — binds a token to a key the client holds, so a stolen token alone is useless.
Token exchange
Trading one token for another with different, usually narrower, privileges.
Client credentials grant
The OAuth 2.0 grant where a service authenticates as itself, with no user involved.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.