Graphql-engine: support multiple JWT secrets

[kkshyu]

for admin secret, we can set in the environment variable: HASURA_GRAPHQL_ADMIN_SECRET and pass x-hasura-admin-secret in header to authorize the permission.

in my scenario, i have two applications sharing the same Hasura API server. Theses two applications have their own JWT secret (specifically different jwk_url). I don't want to duplicate the Hasura server to handle these two applications.

is it possible to set multiple JWT secrets into Hasura server?
or pass the jwt secret to Hasura in header like x-hasura-jwt-secret?
or specifically select the jwk_url in run-time?

[revskill10]

I made a proposal on these problems here: https://github.com/hasura/graphql-engine/issues/1995

I think it relates to your issue here.

[kkshyu]

@revskill10 i've seen your proposal, it is related but i'm not sure whether the secret key management includes JWT secret or not.
because the format of JWT secret is {type, jwk_url, claims_format} and it is different from the other secret (admin-secret and secret key from your proposal are string)

if these two kind of formats can be merged, it will be great~

[kkshyu]

one more different part is that:
in your proposal, it focuses on grant access to clients to access Hasura console as admin
but my scenario is that I have multiple auth servers to grant access to clients to access Hasura API as user

[MeixnerTobias]

I am looking for the same solution.
We run a multi-tenant app with ideally one Hasura instance to serve all tenants.
Every tenant is using a different Cognito user pool as a result the current implementation of HASURA_GRAPHQL_JWT_SECRET does not cover this use-case.
Ideally, I can think of 2 solutions here

1. We can assign a different jwt-secret based on a parameter in the header i.e. x-hasura-org-id
   which then routes the jwt-secret based on the x-hasura-org-id
   HASURA_GRAPHQL_JWT_SECRET: {
   tenant1: tenant1Url
   tenant2: tenant2Url
   }
   whereas tenant1 = x-hasura-org-id
2. Decode the jwt and route to a standard iss provided by the token (Cognito always has the same URL format)

[kkshyu]

I am looking for the same solution.
We run a multi-tenant app with ideally one Hasura instance to serve all tenants.
Every tenant is using a different Cognito user pool as a result the current implementation of HASURA_GRAPHQL_JWT_SECRET does not cover this use-case.
Ideally, I can think of 2 solutions here

1. We can assign a different jwt-secret based on a parameter in the header i.e. x-hasura-org-id
   which then routes the jwt-secret based on the x-hasura-org-id
   HASURA_GRAPHQL_JWT_SECRET: {
   tenant1: tenant1Url
   tenant2: tenant2Url
   }
   whereas tenant1 = x-hasura-org-id
2. Decode the jwt and route to a standard iss provided by the token (Cognito always has the same URL format)

Thanks for @MeixnerTobias explanations. These two methods are great!
My scenario is exactly the same as you. We also use multiple Cognito User Pools for the multi-tenant implementation and would like to share the same Hasura API server.
Currently, we can only write some scripts to launch docker container for Hasura after a new tenant registered. We don't like this method and would like to configure once and use for all.

How about sending the jwt-secret on header for each request?

{
    'x-hasura-jwt-secret': '{"type": "SHA256", ...}'
}

if we send it from the browser, is it unsecured?
i thought the jwk can be public

[MeixnerTobias]

Yes, the format of of jwks urls follow always the same format under .well-known which we can consider public, so I setting it in the http header can work too.

[cthurston]

My need case for this feature is for firebase. If you create a custom token through firebase it is signed with a different issuer (service account) and requires a different JWT_SECRET. Would be great if I could just add an array of acceptable secrets to try.

[
  {
    "type":"RS256",
    "jwk_url": "https://www.googleapis.com/service_accounts/v1/jwk/[email protected]",
    "audience": "<firebase-project-id>",
    "issuer": "https://securetoken.google.com/<firebase-project-id>"
  },
  {
    "type": "RS256",
    "jwk_url": "https://www.googleapis.com/service_accounts/v1/jwk/firebase-adminsdk-xxxxx%40<firebase-project-id>.iam.gserviceaccount.com",
    "audience": "<firebase-project-id>",
    "issuer": "firebase-adminsdk-xxxxx@<firebase-project-id>.iam.gserviceaccount.com",
  }
]

I did find a work around in the firebase docs where you can exchange a custom token for a secureToken using this endpoint: https://identitytoolkit.googleapis.com/v1/accounts:signInWithCustomToken?key=[apiKey]
So this issue is not blocking my workflow at least.

[kesavkolla]

My usecase also very similar. I've single keycloak server where each tenant is one single realm. I want to use single hasura server for all tenants. For keycloak jwks url for each tenant/realm is different. I want an ability to inject the x-hasura-org-id in jwks url.

[smunozp]

Hello

There is any update in this? We have the same situation, we want to serve multitennant with the same server

[NorthJaw]

This can be done using the webhook mode instead of the jwt mode for authentication in Hasura: https://hasura.io/docs/1.0/graphql/manual/auth/authentication/webhook.html

The jwt token along with other headers are passed by Hasura to this webhook which will handle the authentication part and sends back just the session variables to Hasura to use.

A sample auth webhook for Firebase has been provided in the same docs page: https://github.com/hasura/graphql-engine/blob/master/community/boilerplates/auth-webhooks/nodejs-firebase/firebase/firebaseHandler.js

[Nomad-Go]

This can be done using the webhook mode instead of the jwt mode for authentication in Hasura: https://hasura.io/docs/1.0/graphql/manual/auth/authentication/webhook.html

The jwt token along with other headers are passed by Hasura to this webhook which will handle the authentication part and sends back just the session variables to Hasura to use.

A sample auth webhook for Firebase has been provided in the same docs page: https://github.com/hasura/graphql-engine/blob/master/community/boilerplates/auth-webhooks/nodejs-firebase/firebase/firebaseHandler.js

I would call this a workaround. No one wants that extra round trip. Every millisecond counts.