Prisma1: Enhance PATs

[marktani]

• read/write access
• read/write access for specific types/fields
• expiration duration

[marktani]

Thanks to @lastmjs for this detailed write up:

Right now permanent auth tokens provide full read and write access to everything in the database, as far as I understand. Blanket access is undesirable, as I'm sure there are use-cases where you want more fine-grained control. For example, I have a small server function that needs access to only a few entities in my schema, but the permanent auth token I'm using for that server function has access to the entirety of the database. That leaves a larger possible attack vector that is unnecessary.

My proposal is that permanent auth tokens are assigned to a special type of user unique to the permanent auth token (i.e. a server user). That way authorizations and permission queries could work exactly as they do currently. All you would need to do is reference the user id or other properties of the user associated with the permanent auth token.

Anyway, those are my thoughts on the matter.

[kbrandwijk]

Let's make it more generic then, and create the option to generate/revoke a permanent token for any user. That way, you don't need any special functionality for PATs beyond that. Generic is always better :)

[kbrandwijk]

Alternatively, when using Auth0 integration, it would be nice to be able to use their non-interactive client functionality, so you can generate those client ID's in the same place.

[rdela]

Would very much like to see enhanced auth token logic implemented. Allowing a simple config on auth tokens for read-only tokens would simplify code in many scenarios, while reducing attack surface, as mentioned above.

Ability to grant and revoke read/write access for specific types/fields and refined expiration/duration control would be super-nice-to-have bonuses, anything that provides more granular auth token scope is welcome and needed.

However that overlaps with Auth0 integration strategy does not matter to me, what does matter is whether it ends up exposed in a way that Graphcool and GraphCMS can make it easy and obvious to control various levels of access and capabilities after I finish setting it up initially.

Right now because of the lack of token granularity in GraphCMS, it makes more sense for me to separate certain auth concerns, which is creating redundancy and an extra point of failure in scenarios where being able to generate and then co-locate enhanced read-only auth tokens in GraphCMS with the rest of the data would resolve the need for separation. Also prevents useful opportunities for GraphCMS to enable non-technical content editors to control general public and other lesser roles’ access, and makes lesser options that do offer simple read/write tokens alongside PATs look better in comparison.

Reading through old and new Graphcool docs looks like this could simplify ephemeral privileged access scenarios for developers using Graphcool directly as well as providing enormous benefit to GraphCMS.

@marktani I appreciate your comment on #209 though looks like the schema extension function link you reference has changed, …/code/… became …/src/… I think.

If done well, this could be a major boost to security and productivity. Just discovered GraphCMS from GraphQL Radio, and I have been discussing this with @mlukaszczyk and we seem to agree. He is much closer to all of it, mentioned this is under consideration, and directed me to this issue. Grateful for all the Graphcool/GraphCMS contributions and services, I thought I would weigh in, hope you find my thoughts useful!

[marktani]

This issue has been moved to graphcool/graphcool-framework.