Incorrect curl command to request bearer token

[hamza-m-masood]

The curl command to request a bearer token in this section seems incorrect: https://docs.camunda.io/docs/apis-tools/zeebe-api-rest/zeebe-api-rest-authentication/

Why I try to run this command I get the following error:

{"error":"invalid_request","error_description":"Missing form parameter: grant_type"}

This is probably because, the command is passing json into the body but instead, it is expecting a form.

Here is the correct command that worked for me:

curl -X POST \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d 'client_id=zeebe&client_secret=EasySecret&grant_type=client_credentials' \
     https://auth-server-url.com

Tagging relevant people:
@conceptualshark
@christinaausley
@pepopowitz

[pepopowitz]

I've assigned myself. In #4078 (currently in-progress), I'm re-writing auth guides across all APIs, and unifying them all to use the same curl requests for requesting a token. While doing that, I am ensuring that all token requests work.

(You can see an example rewritten guide at that PR's preview site: https://preview.docs.camunda.cloud/pr-4078/docs/next/apis-tools/web-modeler-api/authentication/)

[pepopowitz]

@hamza-m-masood I am not experiencing this error when requesting a token against SaaS (see below). The content-type is specified as application/json, and https://login.cloud.camunda.io/oauth/token seems to have no problem reading the JSON input.

Were you running into this issue against a self-managed instance? I don't have one running right now and haven't verified if it is capable of accepting JSON input instead of form data, but I suspect that might be the case?

Regardless -- can you confirm that the auth curl request on this page works, as it is the version I am planning to use for all auth guides in #4078?

---

My successful token request from the originally linked instructions (with secrets stripped):

❯ curl -X POST --header 'content-type: application/json' --data '{"client_id": "...", "client_secret":"....","audience":"zeebe.camunda.io","grant_type":"client_credentials"}' https://login.cloud.camunda.io/oauth/token
{"access_token":"...","expires_in":81536,"token_type":"Bearer"}%                   

[hamza-m-masood]

@pepopowitz
Thanks for looking into this!

I tested on self-managed only. If you want a quick self-managed deployment, then you have two options:

1. You can use our github action: https://github.com/camunda/camunda-platform-helm/blob/main/docs/gha-workflows.md
2. You can have an instance running locally on your machine: https://github.com/camunda/camunda-platform-local

The above curl request you mentioned did not work for me in my self-managed instance. I still get the same error.

[pepopowitz]

@hamza-m-masood and I talked in DMs, and I'm sharing the outcomes here:

• The SaaS authentication endpoint accepts either JSON parameters or form-data parameters in auth requests.
• The out-of-the-box Self-Managed instance accepts form-data in auth requests, but does not accept JSON parameters.
• In my active PR to revamp auth guides (feat: unify API Auth docs (Admin, Camunda 8, and Web Modeler APIs) #4078), I'm rewriting all guides to include a tab-selector for specifying a SaaS environment or Self-Managed. However, that interface can be easy to overlook.
• In feat: unify API Auth docs (Admin, Camunda 8, and Web Modeler APIs) #4078, I coincidentally ended up with a curl request for SaaS that sends JSON params, and a curl request for Self-Managed that sends form-data parameters. Both of these work in their respective environments. However....
• Since the tab selector is easy to overlook, it is a non-zero likelihood that a SM user will capture the SaaS request and plug in their variables/URL, and get the failure message described in this issue.
• Thus, since form-data requests work for both SaaS and Self-Managed, it makes sense to convert my auth rewrites to use form-data in the SaaS guidance. In the event that a user accidentally captures the SaaS request for their SM environment, the request would likely work in the out-of-the-box SM environment.

These changes will be handled as part of #4078, and I'll update there to make sure I don't miss it. I will leave this issue open, until #4078 is complete.

[pepopowitz]

For what it's worth, rewriting the curl command to use form variables instead of JSON, especially with line-breaks, makes it much nicer to read, too. It's much easier to find the places to drop in your id/secret:

After:

Before:

So this is an all-around win, thanks for raising it @hamza-m-masood.