Authorization and authentication

[calebmer]

This PR's goal is to add authorization and optional authentication to PostGraphQL. As of the opening of this issue I have only added authorization support using JWTs. Look at the tests, look at the readme, and look at this specification and tell me if you like this authorization schema. Authentication (creating tokens) will be decided later on.

[hardchor]

I like the spec, but would you just parse all claims globally or, or namespace them, e.g.

{
  "roles": {
    "sub": "postgraphql",
    "role": "user",
    "user_id": 2
  }
}

We've used JWTs in the past to store arbitrary data (that needed to be trusted), which would get picked up and set as a role with your solution.

[calebmer]

Only the top level role would be used to set the role. If there was a nested object it would be stringified. So role inside the roles object would not be used to set the role. Does this still cause conflicts?

If so we could have a flag in the JWT to switch it off.

[hardchor]

Ah sorry, I wasn't aware it's only the role field that gets set, everything else can get discarded if not needed. If it's just role, then chances for collisions are relatively low.

[calebmer]

@hardchor is there a way I could improve the documentation/specification to make this more clear?

[hardchor]

I just wasn't quite aware of how authorisation in Postgres works (do very little DB related these days). After reading the spec again, it does make sense!

[hardchor]

Are you going to pass the token / claims in through the GraphQL context? I'm doing the request handling myself (and just use createGraphqlSchema as discussed) and would also do JWT decoding / verification.

[calebmer]

Currently, the token is used to run some queries on the PostgreSQL client and is unused by resolvers so it isn't needed in the context. I also don't want to be setting the local variables more than once so putting token serialization in the resolver isn't optimal. Take a look at createServer.js for the code I'm using currently to run a request.

I think what I'll probably do is make a small module (pg-jwt probably) which will implement the specification so you can serialize a token from anywhere.

I could also add a helper function, executeGraphqlQuery or getGraphqlContext to help setup the context.

[calebmer]

I was going to wait to also implement authentication before merging this PR, but I don't have any strong ideas at the moment. How would everyone feel if I merged and released this and work on an authentication solution in another PR?

Releasing this would not be a breaking change, servers would still work even if they never use tokens. People using PostGraphQL as a library would not be affected at all by this PR as it only changes code in the server.

[hardchor]

I'd say handle authorisation and authentication separately and get it in!

[calebmer]

Authorization support has been added in 1.2.0! Documentation on the feature isn't very rich, I'm going to wait for authentication before writing comprehensive documentation on authorization/authentication