Secure your requests
Authentication
Typegraphs supports multiple auth schemes for incoming requests including:
Each scheme relies on tokens that will be expected on the Authorization
header of any incoming request. Information extracted from any found tokens will then be added to the context of every request. Each scheme allows for different secrets to be encoded in the tokens, secrets like user identification and access tokens. You can then use policies to examine the context and determine if a request is allowed access to parts of your typegraph. You can also inject data from the context, to set materalizer inputs for example, using from_context
.
The following example uses basic authentication in order to only allow access for admin users. Basic authentication relies on a username and password pair. We specify the password through typegraph secrets with the format BASIC_{username}
. In this case, the secret BASIC_andim=password
is set.
Note, the token is encoded in base64. Decoded, it'd read andim:password
.
If you were to try to send a request without the header, you'd notice that get_full_context
still returns a result. An empty object. Authentication is only responsible for populating the context object and without a policy to shoot down the request, it'll access the materalizers.
On the other hand, get_context
returns an empty object when no header is found. from_context
acts as guard preventing the materalizer from being accessed unless the named data is found in the context.
More details about authentication can be found here.
Policies
The primary authorization paradigm used in typegraphs is policy based access control. Policies are small pieces of logic that evaluate a request and determine whether access is allowed or not. They're attached to materalizers and are evaluated whenever a request tries to access the materalizer.
Concretely, policies are implemented using custom function. These functions take the request's context object as input and return an optional bool. Typescript functions running on DenoRuntime
is the recommended way for writing policies today and the following example demonstrates how.
Before anything, the following secrets are required to enable the basic authentication scheme.
typegates:
dev:
# ..
secrets:
policies:
BASIC_admin: "admin_pass"
BASIC_user: "user_pass"
More than one policy can be attached to a single materalizer and combining policies allows for compositionaly defining our access control rules. If a materalizer has more than one policy, they are evaluated in turn and:
- If any one of attached policy returns
true
, the request immediately gains access. - If a policy returns
false
, the request is immediately denied access. - If the policy means to defer decision to other attached policies, it can return null instead.
- If all attached policies return
null
, the request is denied access.
There are helper functions on the Policy
object that allow easy construction of common policy patterns.
Policy.public
: allow any request.Policy.internal
: allow requests originating from within typegraph like custom functions.Policy.on
: use different policies depending on request effect. Useful for policy shared across many materalizers.Policy.context
: generate a policy using a simple pattern matching on context object fields.