Just wondering: graph.cool seems to integrate well...
# prisma-whats-new
q
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.)
a
@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.
q
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.
a
So, you would like to define permissions on graphcool Types within Auth0?
I think the only way to do it right now is create a server-side component (like webtask.io) that accesses graphcool with a permanent access token, and then you apply the permissions set in Auth0 to the results you get from graphcool before returning them to the users.
Even if graphcool would extend their Auth0 support, I have no practical idea how those permissions at Auth0 would interact with graphcool Types.
q
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.
a
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.
q
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)
a
q
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)
Sure, I will...
a
It's a natural extension to using Auth0 tokens for authentication, which is already possible. Great idea!