Feature Request: Support for RS256-Signed JWTs and OAUTH Providers in Superset API Authentication

[user1500177]

@rusackas @rdubois @dosu

I have successfully configured Superset to use Zitadel as the OAUTH provider, and users under my Zitadel application can log in via the Superset UI without any issues. Below is the configuration snippet:

AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
{
'name': 'Zitadel',
'token_key': 'access_token',
'icon': 'fa-address-card',
'remote_app': {
'client_id': client_id,

        'client_kwargs': {
            'scope': 'openid profile email',
            'code_challenge_method': 'S256'
        },
        'api_base_url': f'{domain_url}oidc/v1/',
        'access_token_url': f'{domain_url}oauth/v2/token',
        'authorize_url': f'{domain_url}oauth/v2/authorize',
        'jwks_uri': f'{domain_url}oauth/v2/keys'
    },
}

]

Context:
I created an automation script to upload dashboards to Superset. However, I encountered issues when trying to authenticate programmatically using a Personal Access Token (PAT) or JWT from a Zitadel service user account. Below are the scenarios I tested:

Using a Zitadel PAT:
The request to /api/v1/security/csrf_token/ fails with the error:
{"msg": "Not enough segments"}
This indicates that the PAT is not recognized as a valid JWT (And its true the PAT from the Zitadel for service user are not JWT)

Using a Zitadel ID Token:
The same ID token that allows a user to log in via the Superset UI fails when used to request a CSRF token. The error returned is:
{"msg": "The specified alg value is not allowed"}
This suggests that the API endpoint rejects RS256-signed JWTs (id_token is a JWT i verified), even though the same token works for UI login.

Using a Zitadel JWT Access Token for the service user:
Similarly, the RS256-signed access token from Zitadel fails with the same error:
{"msg": "The specified alg value is not allowed"}

Observations:
The dashboard upload automation works perfectly when using a db user. The flow involves obtaining an HS256-signed access token via the /api/v1/security/login endpoint and then using it to fetch the CSRF token.
However, when using Zitadel as the OAUTH provider, the /api/v1/security/csrf_token/ endpoint does not accept RS256-signed tokens, even though the same tokens work for UI login.

Here’s the working flow for a db user:

ACCESS_TOKEN=$(curl -s -k --request POST --url https://<SUPERSET_DOMAIN>/api/v1/security/login
--header 'accept: application/json'
--header 'authorization: Basic Og=='
--header 'content-type: application/json'
--data '{
"username": "username",
"password": "passwordofuser",
"provider": "db"
}' | cut -d: -f2 | cut -d" -f2)

FROM research i got to know that only the db and the ldap could be given @ provider , COULS you confirm , and is it possible to use the same Provider name that we set in the OAUTH_PROVIDERS ? , or atleast it should be possible to use the ACCESS_TOKEN in the follwing request which we get from the same Providers domains right?

CSRF_TOKEN=$(curl -k -s -c cookies.txt --request GET --url https://<SUPERSET_DOMAIN>/api/v1/security/csrf_token/
--header 'accept: application/json'
--header "authorization: Bearer $ACCESS_TOKEN"
--header 'content-type: application/json' | cut -d: -f2 | cut -d" -f2)

curl -k -s -b cookies.txt --url https://<SUPERSET_DOMAIN>/v1/dashboard/import/
--header 'accept: application/json'
--header "authorization: Bearer $ACCESS_TOKEN"
--header 'content-type: multipart/form-data'
--header 'referer: https://<SUPERSET_DOMAIN>'
--header "x-csrftoken: $CSRF_TOKEN"
--form 'formData=pathfordashboard.zip'
--form overwrite=true
--form 'passwords={"Something": "Something"}'

Questions and Feature Requests:
1.Support for Custom OAUTH Providers in the /api/v1/security/login Endpoint:
Currently, the parameter in the /api/v1/security/login endpoint only supports db and ldap. Will future updates include support for custom OAUTH providers like Zitadel (THAT WE CONFIGURED in superset_config.py)? This would allow us to authenticate programmatically using the same OAUTH configuration already set up for UI login.

2.Support for RS256-Signed JWTs in API Authentication:
It appears that the /api/v1/security/csrf_token/ endpoint only accepts HS256-signed JWTs for Bearer tokens[YOU COULD CORRECT ME IF I AM WRONG , is this delibrate that superset expects the JWT for this request to be HS256 signed?], Thats what i got to know from the reading , please correct me if i am wrong. Can you add support for RS256-signed JWTs be added to align with modern OAUTH standards? This would allow tokens issued by providers like Zitadel to work seamlessly for both UI and API authentication.

3.Clarification on Current Behavior:
Is it correct to assume that the /api/v1/security/csrf_token/ endpoint only accepts HS256-signed tokens because it relies on the /api/v1/security/login endpoint, which generates HS256 tokens for db and ldap providers? If so, is there a plan to decouple this dependency and allow RS256 tokens from OAUTH providers to be used? COULD you add this as a feature because it would enable us to use upload dashboards via API itself (With the Supreset_config that we have already set up and working for the Zitadel users under superset app- AS THOSE USERS CAN ALREADY Login VIA UI perfectly - the id_token for such users also use the RS256 token but they were able to sign in to supreset.)

[dosubot[bot]]

Superset's API authentication currently only supports the 'db' and 'ldap' providers via the /api/v1/security/login endpoint; custom OAUTH providers configured in OAUTH_PROVIDERS (like Zitadel) are not supported for programmatic login through this endpoint. The JWT tokens issued for API authentication are signed with HS256 by default, as set in the configuration, and the /api/v1/security/csrf_token/ endpoint enforces this algorithm restriction—RS256-signed tokens from OAUTH providers are rejected by design, even though they work for UI login. There are no open or recent pull requests or documentation indicating plans to support RS256-signed JWTs or custom OAUTH providers for API authentication at this time. For automation, some users rely on session cookies from browser logins or use the Superset CLI as a workaround. Supporting RS256 or custom OAUTH tokens for API authentication would require extending the backend authentication modules and is not currently available in Superset's core implementation.
Source: superset/config.py
Discussion: API tokens stop working after switching to LDAP
Custom middleware and SecurityManager for dual JWT flows

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}