Authorization in your remote schema server¶
Table of contents
Introduction¶
This page gives an overview of how to manage authorization for your remote schemas.
Authorization basics¶
Hasura will forward the resolved x-hasura-*
values as headers to your remote
schema. You can use this information to apply authorization rules in your
server. You don’t have to redo authentication in your remote schema server. Native fine grained access control for remote schemas will be released soon.
You can also configure Hasura to have (as shown here):
- static header values that are sent to the remote server
- forward all headers from the client (like
Authorization
,Cookie
headers etc.)
In case there are multiple headers with same name, the order of precedence is:
configuration headers > resolved user (x-hasura-*
) variables > client headers.
So for example, if the client sends an Authorization
header, and the
configuration also has an Authorization
header, the configuration header value
will selected.
Note
The headers from the client behave similarly to the authorization system. If
x-hasura-admin-secret
is sent, then all x-hasura-*
values from the
client are respected, otherwise they are ignored.
Cookie header from your remote GraphQL servers¶
Set-Cookie
headers from your remote schema servers are sent back to the
client over HTTP transport. Over websocket transport there exists no means
of sending headers after a query/mutation and hence the ``Set-Cookie`` headers are
not sent to the client. Use HTTP transport if your remote servers set cookies.
Bypassing Hasura’s authorization system for remote schema requests¶
It might be necessary sometimes to bypass Hasura’s authorization system (calling the configured webhook, or validating the JWT), for requests that are for a remote GraphQL server.
For example, you have a remote GraphQL server which does authentication, i.e. signup and login, and you have added it as a remote schema. In this case, you would not want to perform Hasura’s authorization when the user is making a login/signup request.
There is no first-class option to currently do this via any configuration in Hasura. However a similar solution can be achieved by the following workarounds:
Bypassing webhook authorization¶
If you have a webhook authorization setup, in the normal scenario, your authorization
webhook would return 200
on success and 401
if it is either unable to authorize the current request or if
the authorization information is absent (like cookie, authorization header etc.)
To bypass the webhook auth:
- the webhook should respond with
200
andx-hasura-role: anonymous
instead of a401
when the authorization information is absent or if it fails to resolve the authorization information. - when adding the remote schema, check the
Forward all headers from client
option so that the remote server will get the relevant cookie/header (from the client) and the roleanonymous
.
Bypassing JWT authorization¶
If you have a JWT authorization setup, to bypass the JWT auth:
- your authentication server should generate a static JWT token for
anonymous
i.e. unauthenticated users. - when adding the remote schema, check the
Forward all headers from client
option so that the remote server will get the JWT (from the client).
For example, the generated JWT can be:
{
"sub": "0000000000",
"iat": 1516239022,
"role": "anonymous",
"https://hasura.io/jwt/claims": {
"x-hasura-allowed-roles": ["anonymous"],
"x-hasura-default-role": "anonymous"
}
}
Hasura will get this JWT and successfully validate it. When your remote server receives this JWT, it should
specifically validate the JWT and, for example, check for the role
key in the JWT. If it is set to anonymous
,
then it should consider the request as unauthenticated.