How are Access Service Token JWTs supposed to be used?
In the Zero Trust dashboard, each request using a Service Token shows up as a "Login". I assumed this was because perhaps I was using them wrong, so I tried just using the cookie (from an initial request) for subsequent requests and omitting the
cf-access-client-id and cf-access-client-secret headers... but this returns a 401/403 (I don't recall, because this was a week ago). I tried extracting the JWT from the cookie and using it in place of the cf-access-client-secret header, and a bunch of other things I thought might be the "correct way", but nothing worked. The documentation is pretty light on this topic, so I was wondering if I'm missing something. Its obviously not the end of the world having each request showing up as a login... although I'd rather it didn't. But I'm just so confused because the docs (https://developers.cloudflare.com/cloudflare-one/identity/service-tokens/#connect-your-service-to-access) literally say: "If the service token is valid, Access generates a JWT scoped to the application. All subsequent requests with that JWT will succeed until the expiration of that JWT." But what does that even mean if there's no way of using the JWT for subsequent requests? I've scoured the web for answers, and found several posts/questions from people with the exact same question... and they never have any answer below them 😭Cloudflare Docs
Service tokens · Cloudflare Zero Trust docs
You can provide automated systems with service tokens to authenticate against your Zero Trust policies. Cloudflare Access will generate service tokens …
31 Replies
the JWT token is sent to you via CF_Authorization cookie, so any browser can automatically store that token and seamlessly use this feature. But in server we don't have a cookie jar to automatically store the cookie, so you will have to manually extract and store it
assume that you have domain
example.com protected by zerotrust, my approach is:
1. Make a GET request to example.com with CF-Access-Client-Id and CF-Access-Client-Secret
2. Extract cookies via Set-Cookie header responded by CF Access and get the CF_Authorization cookie. It will look like this:
(result maybe different according to setting in Zero Trust Application)
3. Store that cookie somewhere else, in my case I store it in CF KV. Everytime I request any resource in example.com, I append the cookie value acquired like above to the Cookies header, even when you are sending request from server.
in the document it said that CF_Authorization header can work too, but for some reason it does not work as expected, so I use the cookie header approach, which simulate cookie sending like a browserThats the thing... I implemented a cookie-jar, which is sending the cookie back to the endpoint... but it fails (401/403) 🙈
what's the error message?
I'll have to grab that code again and get back to you. This was a week ago, and reached out on Twitter about it, and nobody responded 😛
I'm wondering if there's maybe some other config on the access app to make this work.
unless you are a big enterprise or you are on your own XD. At least CF are kind enough to have this discord server and response to our request on their help forum
we dont have such luxury when we use AWS
you have to add a policy whose action set to Service Auth
Yeah I have that setup. Ran into that issue a while back when first using Service Tokens haha 😛
then under the
Assign a group section, you have to choose a group which has your access tokenI'm just gonna try replicate on my personal Cloudflare account now 🙂
You will need an access group which reference a service token like this:
It has to be an access group? I can't just add it under "Create additional rules"?
then attach that group to a policy like this
I haven't tried that approach tho
OK so I've replicated it now. 1 second while I take some screenshots 😛
if you've added that token to an existing policy and it does not work then I'm afraid that you will need to create a separate
Service Auth policyHmmm
btw a group above means that your Access Entity needs to have a feature defined in a group, like an email belongs to
@company.com group
an service token does not represent anyone who belong to a group so it will fail
that's my assumption
btw they have a separated action named Service Auth so it must have a purposeYeah, I would have assumed the "Service Auth" action made everything for a service token work.
Thats why I'm suspecting something isn't quite right here.
The docs literally don't say any of this extra stuff. And I can gain access to the app when using the 2 clearly defined cf-access-* headers.
But just not when using the JWT in a cookie.
Cloudflare Docs
Validate JWTs · Cloudflare Zero Trust docs
When Cloudflare sends a request to your origin, the request will include an application token as a Cf-Access-Jwt-Assertion request header and as a …
Yeah thats different though.
Thats on the origin-side of things.
this document said I can have that in
Cf-Access-Jwt-Assertion but it didn't work XDThat header is injected by Cloudflare AFAIK.
well I guess that's how to config an access policy to accept
Service Token. I was digging documents and retry for a few hours a few months ago to make it work XDHere I make a request with the service token's client ID and secret. And I get through...
Then I take the cookie from the response (I made the actual request with
-v so cURL would show the response headers, but I've hidden that in the first screenshot), and send it to the same endpoint, and it returns a 403 (Forbidden).
This is what the HTML contains... so essentually the same as if I open the page up in the browser.
I tried using an access group, but that doesn't make any difference.
had you created a separated policy just for Service Auth?
@Jacob Marshall, did you ever get this working? I am running into the same issue and it is infuriating that I've followed the docs exactly as they say and I'm just getting back a non-descript "forbidden" 401/403 response like you
@mutatedllama So… short answer - no. Long answer is that I believe there might be a workaround. I reached out to somebody via Twitter DMs and they said that there was a bug in zero trust that was preventing this from working as intended. I’ll see if I can find more details. It was a while ago now haha.
Ok this turned out to be a very silly edge case on our side. If you add an allow policy to that app, it'll work just fine including the Access JWT. Otherwise it blocks without the service token attached. We're trying to figure out how to change this without a breaking change. But if you add an empty Allow policy for now, it'll work as you expect.That’s a direct quote from https://x.com/kennyjohnsonatx. However I will say… I did try the workaround and it didn’t work. So… your mileage may vary.
Wow, thanks for this! That is crazy. I'll give that a try and see how it goes!