Just wondering: graph.cool seems to integrate well with auth0. Well, it seems so... I can't find how to check JWT fields to authorize people (database-wide, or 'type'-specific). Is there an 'auth0-JWT authorization' possibility? (It doesn't really make sense to me to add user management to graph.cool, if auth0 already takes care of it.)

@qsys Documentation says: Signing in a User No special step is needed to obtain a token for Auth0. You can use the same idToken to authenticate a request that you would use for the createUser mutation. You can configure the expiration duration of these tokens in the settings of your Auth0 account.

Yes, but I'm not talking about token validity only, I'm talking about more fine-grained access. For example: 1. In auth0, one adds a field

approved

and only

approved

users can do something (so, one has to check if the

approved

field is set, and it's set to true) 2. In auth0, one stores roles and permissions and groups of a user. Some users can access other stuff than others. In this case, permission is based on the roles set in something like

app_metadata/roles

. The reason to do this is: a user admin can handle auth0, but may not be able to work with graph.cool. So I prefer to keep all the user-specific things/data in auth0.

So, you would like to define permissions on graphcool Types within Auth0?

Allright, thanks... Well, I could think of a way to achieve it in graphcool: if (some) http-request headers, such as X-Authorization, are passed into filters, these could be used. Or, well, let's say that the JWT is validated, it could still be passed into a custom (permission)filter? For now, I guess I'll have to put a webtask in front of graphcool.

So basically, initial support for permissions would 'only' require having access to the token inside the permission query? Because that's quite a concrete FR.

right... Having access to the token data/payload would be great. In the flow, I'd something like: 1. There's a JWT validation check - at this point, the signature is validated; this part is done 2. The JWT payload is turned into (nested?) key-values which are in the permission query (so to add fine-grained permission logic)

Can you submit a PR for that? https://github.com/graphcool/feature-requests/issues

One might make it a 3 step thing as well: 1. JWT validation 2. general JWT logic (for 'all' fields) 3. specific JWT logic (per type or field)

It's a natural extension to using Auth0 tokens for authentication, which is already possible. Great idea!