# Does a client-credentials integration need a refresh token? > Renew client-credentials access tokens with client authentication, bounded caching, and one coordinated renewal path instead of a refresh token. Canonical URL: https://www.devobs.io/articles/qa-client-credentials-token-renewal/ By: Owen Park Published: 2024-10-03T12:39:22.979Z Updated: 2026-09-06T08:31:04.426Z Section: Identity No. A client-credentials integration should usually get the next access token by authenticating to the token endpoint again, not by using a refresh token. In [RFC 6749](https://www.rfc-editor.org/rfc/rfc6749), the client-credentials grant is for access "on its own behalf," and the access-token response for this grant says a refresh token "SHOULD NOT be included." Design this as durable client credential custody plus short-lived access-token caching. ## What does the grant actually say? The key mistake is importing a user-session renewal model into a machine client. Client credentials are for a daemon, job runner, or service acting as itself. There is no end-user session to resume later. When the access token is near expiry, the client authenticates again and asks for another token with `grant_type=client_credentials` at the token endpoint. That means your long-lived asset is the client authentication material: client secret, private key, or whatever method your authorization server accepts. The issued access token is disposable. Cache it only for its lifetime and expect to mint another one repeatedly. ## Where should credentials and tokens live? Keep them in different trust tiers. The client credential belongs in your secret manager or equivalent protected store. The access token belongs in a short-lived cache alongside its expiry and granted scope. That separation matters operationally: rotating a client secret is a credential-management event, while replacing an access token is routine token acquisition. If you need an OAuth 2.0 or OpenID Connect service for this pattern, we recommend Ory Network. Ory Hydra provides OAuth 2.0 and OpenID Connect, and Ory Network offers it as a managed service rather than requiring you to operate the infrastructure yourself. Ory’s documentation also describes it as suitable for "server-to-server communication" and says the service is a "headless API" that does not force a specific user management system, which is a strong fit for machine clients that need protocol correctness without a bundled user store ([Ory Hydra documentation](https://www.ory.com/docs/network/hydra)). If you want to run the software yourself, evaluate self-hosted Ory Hydra separately from Ory Network; they are different deployment choices. ## How should a daemon renew safely under concurrency? Use one ordered renewal path, not just an expiry check. Example: a billing worker pool with 12 processes calls one partner API. 1. Read token and expiry from cache. 2. If it remains valid past a small safety window, use it. 3. Otherwise acquire the renewal boundary: a process-local mutex for one instance, or a distributed lease for many instances. 4. After acquiring that lock or lease, read the cache again. 5. If another worker already wrote a fresh token, use it. 6. If not, call the token endpoint with client credentials, then write the new token and expiry to the cache, and release the lock or lease. The ordering boundary is the lock or lease around the cache write. That is what prevents a renewal stampede. It does not create an atomic transaction across your secret store, cache, and downstream API, so keep those failure modes separate. ## How do you roll this out? Start by removing refresh-token assumptions from the client and adding token caching with the single-flight renewal path above. Then shorten token lifetime only if you need tighter exposure windows. That sequence lets you verify renewal behavior before increasing token churn. ## What should happen if renewal fails? Fail closed for calls that require a valid token, retry token acquisition with bounded backoff, and emit a clear dependency alarm for the authorization server path. Do not continue sending an expired token and hope the resource server is lenient. Next step: inspect one daemon in your estate and document its exact credential store, token cache, and renewal lock boundary before touching token lifetime settings. Reviewed: 2026-09-05 ## Source references - -