Hi everyone,
I was just setting up my first Cloudflare Access policy to protect an internal dashboard, and I noticed the option to create a "Service Token" alongside the regular identity-based rules. The documentation calls it a "non-identity-based token," which left me a bit puzzled.
As someone who mostly works with user logins (like Google or GitHub), I'm trying to wrap my head around the practical use case. When would I choose a service token over just adding a user or group to an Access policy? My gut says it's for machine-to-machine communication, but I want to make sure I'm understanding it correctly.
Could someone help clarify with a concrete example? Specifically:
* What kind of service or automation would typically use this token?
* How does the security model differ from a user-based policy?
* Are there any common pitfalls when first implementing them?
I'm especially thinking about scenarios in CI/CD pipelines or internal health checks, but I'd love to hear how others are using them in the wild.
Thanks in advance for helping a newcomer out!
gh2
ship early, test often
You're right on the money with the machine-to-machine thought. A service token is essentially a static, long-lived credential for automated systems, while identity-based rules are for human users with a login session.
Think of a CI/CD pipeline that needs to deploy to a staging environment protected by Access. You don't want to give the pipeline a GitHub identity or have a human manually log in. You'd create a service token, store it as a secret in your CI system (like GitHub Secrets), and have the pipeline present that token in the `CF-Access-Client-Id` and `CF-Access-Client-Secret` headers when it makes requests. The same applies for internal monitoring probes or backup scripts that need to hit a secured endpoint.
The security model is simpler but less granular. The token either works or it doesn't; there's no user context, MFA, or device posture checking. The main pitfall is treating it like a user password. You must rotate these tokens regularly, as they're a prime target if leaked. Also, audit who or what has the token value, because once it's issued, you can't trace a specific request back to an individual machine without your own logging.
Mike
Good example with the CI/CD pipeline. That's the classic use.
You mentioned rotating tokens. It's a pain, but the Cloudflare API actually makes it bearable. You can script it. I run a cron job that:
- Creates a new service token
- Updates the secret in our CI and config stores
- Revokes the old one after a 48-hour overlap period
If you don't script it, rotation just doesn't happen.
Benchmarks don't lie.