I have semi-trusted user agents (in my case, managed mobile kiosks) that need limited access to my backend. These devices do not have users logging in and receiving JWT credentials, so they cannot use my existing JWT auth setup.
I would like to authorize the actions performed by these devices by associating a role to the credentials issued to each device, and and be able to disable credentials for particular devices (for example, if a device is lost or stolen).
I also do use regular user logins with JWT auth for other user agents, so this has to work in tandem with Hasura configured with JWT auth.
Describe the solution you'd like
Solution with API Tokens
I would like to issue individual API tokens to semi-trusted clients. These API tokens would work similarly to X-Hasura-Admin-Secret in that JWT auth is skipped if the token is present in a header (e.g. X-Hasura-Api-Token), however API token based auth would be
a) more limited in their scope -- each token could be mapped to a pre-set role -- an acceptable solution for me at this stage would allow one role to be associated with all api tokens
b) unique tokens can be issued
This fills a gap between the admin secret (which clearly cannot be sent to semi-trusted or untrusted user agents), and JWT auth which will generally already be configured to support per-user authentication.
Solution with JWT Routing
A "routing" mechanism for validating JWT tokens would work: tokens for users can be validated with one mechanism, and tokens issued as api keys could be validated with another mechanism. Matching on the issuer field would be a good way to do this routing.
Create my own JWT validation backend which acts as a proxy and either forwards the JWT to the backend which validates user tokens, or validates semi-trusted user-agents with internally generated custom tokens.
Another approach is to have all of the semi-trusted user agents be "anonymous", but a) that prevents differentiating between these requests and truly anonymous requests, and b) requires opening up the system to anonymous users and therefore eliminating one layer of security.
Another approach is to not use Hasura for this purpose, but rather a custom backend which returns data to these clients, and which in turn internally talks to Hasura using the admin secret.
Another approach is to expose this data via a separate Hasura instance on the same schema, or alternatively on another schema while keeping the specific data needed in sync using native database tools/methods.
If the feature is approved, would you be willing to submit a PR?
Perhaps with appropriate guidance. I do not know Haskell.
Is your proposal related to a problem?
I have semi-trusted user agents (in my case, managed mobile kiosks) that need limited access to my backend. These devices do not have users logging in and receiving JWT credentials, so they cannot use my existing JWT auth setup.
I would like to authorize the actions performed by these devices by associating a role to the credentials issued to each device, and and be able to disable credentials for particular devices (for example, if a device is lost or stolen).
I also do use regular user logins with JWT auth for other user agents, so this has to work in tandem with Hasura configured with JWT auth.
Describe the solution you'd like
Solution with API Tokens
I would like to issue individual API tokens to semi-trusted clients. These API tokens would work similarly to
X-Hasura-Admin-Secret
in that JWT auth is skipped if the token is present in a header (e.g.X-Hasura-Api-Token
), however API token based auth would bea) more limited in their scope -- each token could be mapped to a pre-set role -- an acceptable solution for me at this stage would allow one role to be associated with all api tokens b) unique tokens can be issued
This fills a gap between the admin secret (which clearly cannot be sent to semi-trusted or untrusted user agents), and JWT auth which will generally already be configured to support per-user authentication.
Solution with JWT Routing
A "routing" mechanism for validating JWT tokens would work: tokens for users can be validated with one mechanism, and tokens issued as api keys could be validated with another mechanism. Matching on the issuer field would be a good way to do this routing.
UPDATE: This is basically https://github.com/hasura/graphql-engine/issues/2208 which is apparently already implemented in Hasura Cloud, but not Community.
Describe alternatives you've considered
Create my own JWT validation backend which acts as a proxy and either forwards the JWT to the backend which validates user tokens, or validates semi-trusted user-agents with internally generated custom tokens.
Another approach is to have all of the semi-trusted user agents be "anonymous", but a) that prevents differentiating between these requests and truly anonymous requests, and b) requires opening up the system to anonymous users and therefore eliminating one layer of security.
Another approach is to not use Hasura for this purpose, but rather a custom backend which returns data to these clients, and which in turn internally talks to Hasura using the admin secret.
Another approach is to expose this data via a separate Hasura instance on the same schema, or alternatively on another schema while keeping the specific data needed in sync using native database tools/methods.
If the feature is approved, would you be willing to submit a PR?
Perhaps with appropriate guidance. I do not know Haskell.