Title: OAuth/OIDC Access Token (RS256) Rejected by /api/v1/security/csrf_token/ with "The specified alg value is not allowed

[user1500177]

Superset Version
5.0.0
Context
We have successfully integrated Apache Superset with Zitadel as an external OIDC provider (AUTH_TYPE = AUTH_OAUTH). All user logins via the Superset UI execute the OIDC flow and work correctly, establishing a valid session via cookies.
We are blocked from automating backend tasks (like dashboard upload) because we cannot programmatically authenticate via the API to retrieve the necessary CSRF token.
Zitadel OAUTH Configuration (superset_config.py snippet)
from flask_appbuilder.security.manager import AUTH_OAUTH

AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
{
'name':'ZitadelSSO',
'token_key':'access_token',
'icon':'fa-address-card',
'remote_app': {
'client_id': client_id,
# Client Secret is generally omitted when using PKCE
'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' # Source for RS256 public key
},
}
]

Steps to Reproduce (API Failure)
We tested three types of tokens, with the following results on the /api/v1/security/csrf_token/ endpoint:

Token Type	Signing Algorithm	Result	Implication
Zitadel PAT (Service User)	Opaque String	{"msg": "Not enough segments"}	Token not recognized as a JWT.
ID Token (Normal User)	RS256	{"msg": "The specified alg value is not allowed"}	Correct JWT format, but algorithm is rejected.
JWT Access Token (Service User)	RS256	{"msg": "The specified alg value is not allowed"}	Correct JWT format, but algorithm is rejected.

The failing request template for the JWTs is:
curl -k -s
--request GET
--url https://<SUPERSET_DOMAIN>/api/v1/security/csrf_token/
--header 'accept: application/json'
--header "authorization: Bearer <ZITADEL_RS256_JWT>"
--header 'content-type: application/json'

Actual Behavior
The use of any valid, RS256-signed JWT (ID Token or Access Token) results in an immediate authentication failure due to algorithm rejection:
{"msg": "The specified alg value is not allowed"}

What is the Root Cause for this ??

I saw a Hardcoded HS256 Logic
The critical observation is that the same ID Token that successfully authenticates a user via the OIDC redirect flow (meaning Superset can validate RS256) is rejected by the API's /api/v1/security/csrf_token/ endpoint.
This failure strongly indicates that the generic JWT validator used by the API for the Authorization: Bearer header is defaulting to an internal, HS256-only check, thereby overriding or bypassing the OAUTH provider's configuration.
This behavior aligns with code segments where the algorithm is explicitly limited to the internal default:
Code Snippet Example (from superset/async_events/async_query_manager.py):
def parse_channel_id_from_request(self, req: Request) -> str:
token = req.cookies.get(self._jwt_cookie_name)
# ...
try:
return jwt.decode(token, self._jwt_secret, algorithms=["HS256"])["channel"]
# ...

This persistent, low-level algorithm rejection is a major blocker for API automation for any OIDC provider that uses RS256 signing (the modern standard).
Request: We request immediate guidance on how to enable RS256 validation for the API security endpoints in Superset 5.0.0 to resolve this conflict between successful UI login (RS256 accepted) and failed API authentication (RS256 rejected).

To address this exact error, we have attempted to add or modify the following configuration flags in superset_config.py, none of which resolved the API validation error

1. Primary fix for algorithm mismatch (FAILED)
   JWT_ALGORITHMS = ["HS256", "RS256"]
   We also tried: JWT_DECODE_ALGORITHMS = ["HS256", "RS256"]

2. Related JWT flags also checked/configured (FAILED)
   GUEST_TOKEN_JWT_ALGORITHM = "RS256" Attempted to influence all JWT logiic

[dosubot[bot]]

The root cause is that Superset's API authentication for endpoints like /api/v1/security/csrf_token/ only accepts HS256-signed JWTs for Bearer tokens, and this is hardcoded in the validation logic. This is separate from the OIDC/OAuth UI login flow, which does support RS256. Configuration flags such as JWT_ALGORITHMS, JWT_DECODE_ALGORITHMS, or GUEST_TOKEN_JWT_ALGORITHM in superset_config.py do not affect this API JWT validation—only HS256 is allowed, and this cannot be changed via config. Accepting RS256-signed JWTs for API Bearer authentication would require code changes or a custom security manager implementation. This separation is why RS256 tokens work for UI login but are rejected by the API with "The specified alg value is not allowed" source.

To reply, just mention @dosu.

---

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

[user1500177]

@rusackas @rdubois @dosu

I had successfully configured the Supeset to use Zitadel as the OAUTH provider. And the common users(In Zitadel under my application) are able to login via the UI successfully.

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

Client Secret is generally omitted when using PKCE

'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'
},
}
]

I had created an automation script to upload dashboards to superset but its not working with the PAT from the service user account of Zitadel [Error is "Not enough segments"]
Then i utilized the id_token that is taken from the userinfo endpoint of Zitadel for providing the addtional information (Like the Zitadel role and all and then i later mapp that user to Admin or Gamma etc), With the exact same id_token that the user can use to sign in to Superset (via Zitadel ) also we are not able to obtain the csrf_token BY USING the id_token as the access_token in the request.

The uploading of dashboards is working well when its a 'db' user {When Zitadel was not set up}, while sending the request to endpoint and flow like ::

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)

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"}'

1. I saw that a person can only use the "provider" parameter or header as the "db" or "ldap" , will support for the custom configured Zitadel or other OAUTH be given in the following updates

2. When i checked I also came across materials that the ACCESS_TOKEN from the db provider is HS256 signed JWT and using it in request for CSRF_TOKEN is correctly responding, But using the id_token (of the Zitadel which is a RS256 signed JWT ), we are not able to login the user via the https://<SUPERSET_DOMAIN>/api/v1/security/csrf_token/ endpoint AND the error comes up like {"msg": "The specified alg value is not allowed"} , EVEN THOUGH the same user is able to sign in to superset with Zitadel

3. My whole aim was to sign in a service user who has a PAT or JWT(which is also the RS256 signed one), as i have already configured the OAUTH correctl and user can login ia the UI , I DID expect the endpoints to work too , BUT I GUESS SOMETHING is preventing me from getting the csrf_token from the endpoint(https://<SUPERSET_DOMAIN>/api/v1/security/csrf_token/ , with the access token form Zitadel or JWTs from Zitadel), IS IT BECAUSE THE SUPERSET expect only the HS256 signed access_token (THATS WHAT I UNDERSTOOD , CORRECT ME IF I AM WRONG please....) in the request made to the same csrf endpoint (Which as of now will be got from the https://<SUPERSET_DOMAIN>/api/v1/security/login endpoint and the with the provider options available as "db" OR "ldap"?? ) [REPSOND TO THIS QUERY PLEASE]

4)Is it possible to create a new endpoint via the superset_config, that could be used for uploading the dashboards, by verfying the PAT directly , is that possible or not possible ?

5)Have any one encountered similar problem in the past and solved it ?

[dosubot[bot]]

You're correct—Superset's API authentication (including /api/v1/security/csrf_token) only accepts HS256-signed JWTs issued by Superset itself (via the /api/v1/security/login endpoint with "db" or "ldap" providers). This is enforced by the authentication middleware and is not configurable; RS256-signed tokens from external OIDC providers like Zitadel are rejected with "The specified alg value is not allowed" because only HS256 is allowed for API Bearer tokens. This is separate from the UI login flow, which does support RS256 for OIDC/OAuth logins, but those tokens are not valid for API authentication citation.

There is no current or planned support for using custom OAUTH providers (like Zitadel) for API authentication, and no configuration or feature flag enables this. Creating a new endpoint for dashboard uploads that verifies a PAT directly cannot be done via superset_config.py; it would require code changes.

No known workarounds or solutions have been documented for this issue, and similar problems have not been solved in the community or documentation. For API automation, the only supported approach is to use DB/LDAP users to obtain Superset-issued tokens.

To reply, just mention @dosu.

---

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

[user1500177]

@rusackas @rdubois @sandeep-patel11 @dosu

Hi , why an OAuth token is not recognized by Superset API whereas it works in a human authentication workflow ?

[dosubot[bot]]

Superset has two separate authentication flows: the UI login flow supports OAuth/OIDC providers and accepts RS256 tokens (like those from Zitadel), but API endpoints—including /api/v1/security/csrf_token—only recognize HS256-signed JWTs issued by Superset itself. This is enforced by the API authentication logic, which does not validate or accept external OAuth tokens for Bearer authentication. As a result, OAuth tokens work for human (UI) login but are rejected by the API because only Superset-native HS256 tokens are allowed for API access see code reference.

To reply, just mention @dosu.

---

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