GitHub user user1500177 created a discussion: Feature Request: Support for
RS256-Signed JWTs and OAUTH Providers in Superset API Authentication
@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.)
GitHub link: https://github.com/apache/superset/discussions/35311
----
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]
