GitHub user user1500177 created a discussion: Title: OAuth/OIDC Access Token
(RS256) Rejected by /api/v1/security/csrf_token/ with "The specified alg value
is not allowed
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
GitHub link: https://github.com/apache/superset/discussions/35281
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
