cloudflared access curl integration feedback

[Lekensteyn]

The cloudflared access curl command (docs) can be used to obtain a valid authentication token and include the cf-access-token header with the curl command line. However there were some integration challenges when naively replacing an existing curl invocation by cloudflared access curl:

• The subcommand requires the first argument to be the URL. Therefore the invoking script had to be modified to move the URL to the front.
• The saved token is based on the full URL. If https://www.example.com/download/file.zip was requested, then the file ~/.cloudflared/www.example.com-download-file.zip-token would be created. For my use case, I needed the token to be scoped to a domain. Therefore I had to extract the host from the URL and use cloudflared access login https://www.example.com instead.
• The very first time authentication happens in the browser, a redirect to the original URL occurs. That was undesirable as the URL was a file to be downloaded. It would be nice if the redirect can be disabled in order to unconditionally display the Success page ("You are now logged in and can reach this application. You can close this browser window."), similar to the displayed message when you are already authenticated.
• The cloudflared access login command prints the token. This info is sensitive even if it is only valid for a short time. It is terrible if you are doing a screencast. It would be better if it is hidden, recommending the user to use the cloudflared access token --app=www.example.com command instead.
• The cloudflared access token command does not validate the token online. The token file appears to have an expiry epoch time in the JWT payload, so at minimum that can be verified if available. However due to potential clock skew and server-side expiration, I ended up with the following strategy:
  1. First time? Always call cloudflared access login https://www.example.com
  2. Obtain the token with cloudflared access token --app=www.example.com
  3. If the token is empty, fail with an error.
  4. Success.
• When the token from cloudflared access token is used, a redirect occurs to the login page. Because the final status code is 200 OK, applications which use curl -sL -Hcf-access-token=$TOKEN $URL will end up using the wrong data. Perhaps a HTTP status code other than 1xx and 2xx can be used? For example, 400 Bad Request or 403 Forbidden?
• The cloudflared access curl --help command fails with parse --help: invalid URI for request instead of displaying a synopsis such as cloudflared access curl [options...] <url>. The --allow-request or -ar option is unfortunate, the latter conflicts with curl.

[securitygeneration]

@Lekensteyn makes some great points.

To add to this, I'm experiencing issues with cloudflared access curl <url> when there isn't an existing token for the URL.

In this case cloudflared tries to open the browser to authenticate the user, with the intent of redirecting the user to the requested URL after authentication. Except I've found that when using the curl command, cloudflared does not properly generate the return_url parameter. As an example, when running: cloudflared access curl https://protectedservice.domain.com/protected/path, cloudflared will open the following URL in the browser:

https://protectedservice.domain.com/cdn-cgi/access/cli?redirect_url=https%3A%2F%2Fprotectedservice.domain.com%3Ftoken%3D<token>%253D&token=<token>

Note the redirect_url parameter is effectively https://protectedservice.domain.com (and note the missing path). This results in an Invalid redirect URL error (because the URL without the path does not have a Cloudflare Access application policy associated with it):

In contrast when doing a login by running cloudflared access login https://protectedservice.domain.com/protected/path, cloudflared will open the following URL in the browser:

https://protectedservice.domain.com/cdn-cgi/access/cli?redirect_url=https%3A%2F%protectedservice.domain.com%2Fprotected%2Fpath%3Ftoken%3D<token>%253D&token=<token>

Note the redirect_url in this instance is https://protectedservice.domain.com/protected/path (which is correct), and correctly opens the authentication page (and returns a token upon successful authentication).

I, too, rely on the curl command to programmatically check whether the current token is still valid and results in access to the requested resource. Due to the issues outlined above, this fails, since the process halts in the browser with the Invalid redirect URL error. I thus have to resort to setting a timeout on the curl command, and then running the login command in order to properly retrieve a new token.