Support HTTP header credentials for the authLogin graphql query #1053

New issue

Open

opened 2026-03-04 11:38:35 -05:00 by deekerman · 3 comments

deekerman commented

2026-03-04 11:38:35 -05:00

Owner

Originally created by @vdbe on GitHub (Feb 7, 2026).

Is your feature request related to a problem? Please describe.

Currently to authorize a graphql query all parameters have to be in the body of
the post request. Many tools like the grafana infinity data source
support adding authentication values via HTTP header, but do not support modifying the request body.
This makes it difficult to use them with the cloudbeaver graphql api.

Describe the solution you'd like

There are multiple ways to support authentication via headers. Two possible approaches are outlined below.

Option 1: Standard Auhtorization header

Suport using Authorization: Bearer <TOKEN> for authLogin.
The Reverse Proxy handler already apperts to support header-based authentication:
github.com/dbeaver/cloudbeaver@b0205e34c7/server/bundles/io.cloudbeaver.service.auth/src/io/cloudbeaver/service/auth/RPSessionHandler.java (L97-L100)
This seems like the cleanest solution.

Option 2: Custom headers mapped into the credentials object

Allow custom headers to be injected into the credentials object when authenticating
github.com/dbeaver/cloudbeaver@b0205e34c7/server/bundles/io.cloudbeaver.service.auth/src/io/cloudbeaver/service/auth/WebServiceBindingAuth.java (L43)
I would be happy to implement this or provide a POC.

Describe alternatives you've considered

Using the reverse proxy provider.

Adds additional deployment complexity
Weakens security by expanding the trusted surface area

Additional context

Below is an example request using Option 2, where authentication data is partially provided via HTTP headers:

echo -n 'Password123' | md5sum | tr a-z A-Z

curl http://localhost:8978/api/gql \
  -Ss \
  -X POST \
  -H "Content-Type: application/json" \
  -H "X-Cloudbeaver-user: admin123" \
  -d @- <<'EOF'
{
  "operationName": "authLogin",
  "query": "
    query authLogin($provider: ID!, $credentials: Object!, $useHeaders: Boolean) {
      auth: authLogin(provider: $provider, credentials: $credentials, useHeaders: $useHeaders) {
        userTokens {
          userId
        }
      }
      projects: listProjects{
        id
        global
        shared
        name
        description
        canEditDataSources
        canViewDataSources
        canEditResources
        canViewResources
      }
    }
  ",
  "variables": {
    "provider": "local",
    "useHeaders": true,
    "credentials": {
      "password": "42F749ADE7F9E195BF475F37A44CAFCB"
    }
  }
}
EOF

Originally created by @vdbe on GitHub (Feb 7, 2026). **Is your feature request related to a problem? Please describe.** Currently to authorize a graphql query all parameters have to be in the body of the post request. Many tools like [the grafana infinity data source](https://github.com/grafana/grafana-infinity-datasource) support adding authentication values via HTTP header, but do not support modifying the request body. This makes it difficult to use them with the cloudbeaver graphql api. **Describe the solution you'd like** There are multiple ways to support authentication via headers. Two possible approaches are outlined below. Option 1: Standard `Auhtorization` header Suport using `Authorization: Bearer <TOKEN>` for `authLogin`. The Reverse Proxy handler already apperts to support header-based authentication: https://github.com/dbeaver/cloudbeaver/blob/b0205e34c7fcc67b4d84e0e524c4b1fb5a307bc7/server/bundles/io.cloudbeaver.service.auth/src/io/cloudbeaver/service/auth/RPSessionHandler.java#L97-L100 This seems like the cleanest solution. Option 2: Custom headers mapped into the `credentials` object Allow custom headers to be injected into the `credentials` object when authenticating https://github.com/dbeaver/cloudbeaver/blob/b0205e34c7fcc67b4d84e0e524c4b1fb5a307bc7/server/bundles/io.cloudbeaver.service.auth/src/io/cloudbeaver/service/auth/WebServiceBindingAuth.java#L43 I would be happy to implement this or provide a POC. **Describe alternatives you've considered** Using the reverse proxy provider. - Adds additional deployment complexity - Weakens security by expanding the trusted surface area **Additional context** Below is an example request using Option 2, where authentication data is partially provided via HTTP headers: ```bash echo -n 'Password123' | md5sum | tr a-z A-Z curl http://localhost:8978/api/gql \ -Ss \ -X POST \ -H "Content-Type: application/json" \ -H "X-Cloudbeaver-user: admin123" \ -d @- <<'EOF' { "operationName": "authLogin", "query": " query authLogin($provider: ID!, $credentials: Object!, $useHeaders: Boolean) { auth: authLogin(provider: $provider, credentials: $credentials, useHeaders: $useHeaders) { userTokens { userId } } projects: listProjects{ id global shared name description canEditDataSources canViewDataSources canEditResources canViewResources } } ", "variables": { "provider": "local", "useHeaders": true, "credentials": { "password": "42F749ADE7F9E195BF475F37A44CAFCB" } } } EOF ```

deekerman added the

xf:authentication

labels

2026-03-04 11:38:35 -05:00

deekerman commented

2026-03-04 11:38:48 -05:00

Author

Owner

@dariamarutkina commented on GitHub (Feb 9, 2026):

Hello, @vdbe !

Could you please clarify which CloudBeaver edition you are using?

CloudBeaver Enterprise Edition supports API access tokens. You can find the documentation here:
https://dbeaver.com/docs/cloudbeaver/Generate-API-access-token/

You are welcome to try it with a free 2-week trial 🦫

@dariamarutkina commented on GitHub (Feb 9, 2026): Hello, @vdbe ! Could you please clarify which CloudBeaver edition you are using? CloudBeaver Enterprise Edition supports API access tokens. You can find the documentation here: https://dbeaver.com/docs/cloudbeaver/Generate-API-access-token/ You are welcome to try it with a [free 2-week trial](https://dbeaver.com/trial/) 🦫

deekerman commented

2026-03-04 11:38:49 -05:00

Author

Owner

@vdbe commented on GitHub (Feb 9, 2026):

I'm using the team edition with the API access token provider.
The issue is that the token must be included in the request body rather than (optionally) in the request header, like described in option 1.

@vdbe commented on GitHub (Feb 9, 2026): I'm using the team edition with the API access token provider. The issue is that the token must be included in the request body rather than (optionally) in the request header, like described in option 1.

deekerman commented

2026-03-04 11:38:50 -05:00

Author

Owner

@dariamarutkina commented on GitHub (Feb 9, 2026):

Thanks for the suggestion and for sharing your use case! 💙
This is a good idea, and we plan to add support for this in one of the upcoming sprints 🦫

@dariamarutkina commented on GitHub (Feb 9, 2026): Thanks for the suggestion and for sharing your use case! 💙 This is a good idea, and we plan to add support for this in one of the upcoming sprints 🦫