GraphQL Endpoint Authentication and Authorization

[cdelgadob]

I am wondering how are you implementing authorization on a graphql endpoint in AWS.

My idea is to use Cognito Groups and match them with allowed queries/mutation per group in a custom authorizer lambda function.

Is this something reasonable?

It is important that the graphql lambda function is not hit by any unauthorized request.

[cdelgadob]

Hi,
Before my post obviously I didn't read all the threads about it.
I guess the question now is: what is the status of this? I can't find any doc/post/code/example... ?
Thanks

Carlos

[dalerka]

I'm also interested in this and welcome any advice. Here's some relevant discussion.

[sid88in]

@dalerka @cdelgadob its a valid concern. Looks like AWS provides different ways to authenticate AWS API Gateway http://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html

We can design/prioritize this in coming days.

[sid88in]

Also some info here http://dev.apollodata.com/react/auth.html

[sid88in]

@nikgraf I have implemented Cognito User Pool Authentication on my local branch. Will create a PR on this soon. 2 Problems trying to solve now after authenticating my endpoints : 1) how to pass token to graphiQL endpoint 2) my resolver now has a rest wrapper and this rest endpoint is also secured, so my POST request to graphql endpoint must pass authorization header token value to resolver and another rest endpoint

[sid88in]

well 1) got resolved :) I added chrome plugin to add auth header (now client can generate token which is valid for 1 hour and then set this in the chrome header) and graphiQL works!

Looking into 2)

[sid88in]

OK resolved 1) and 2)

unfortunately there is no serverless plugin to mock cognito
dherault/serverless-offline#264

[sid88in]

OK great! this works dherault/serverless-offline#118

[buggy]

I think it's import to consider authentication and authorization as two different problems.

Authentication is how someone proves who they are to the GraphQL server. The most common approach here is to include an Authorization header with a token (for example a JWT).

My personal feeling on using authorizers (either custom or Cognito) with the API GW is that they're great in a REST environment where I can tell from the URL who should be able to access it but completely inappropriate for GraphQL. For example: I can protect POST, PUT, DELETE to /pages and /page/:n but allow unauthenticated access to GET /pages and /pages/:n using authorizers

With GraphQL everything sits behind a single API endpoint. If you put an authorizer on it then the entire GraphQL API ceases to be publicly available which is a problem if you want to allow self registration, login, password reset or other functionality for anonymous users while restricting other operations/information. Using the previous example I should be able to request pages anonymously with only the mutations to create, update and delete pages restricted.

For authorization Facebook seems to recommend doing it in the business logic or the resolver. This approach allows partial failures where a user may be authorized to access some information but not all. The GraphQL spec itself talks about partial errors "A response may contain both a partial response as well as encountered errors in the case that an error occurred on a field which was replaced with null." See http://facebook.github.io/graphql/October2016/#sec-Response

Typically I put authentication into the handler. It will validate the token from the Authorization header and lookup the relevant user. The user information is then put into the request context that is available to the resolvers. This allows the resolvers to restrict access to information or to pass user information on to the business logic. It also frees the resolvers from authentication as they are told who the user is.

[sid88in]

@buggy thanks for your valuable inputs. I completely agree that authentication and authorization as two different problems and must be handled differently (also explained here https://dev-blog.apollodata.com/a-guide-to-authentication-in-graphql-e002a4039d1 and https://dev-blog.apollodata.com/auth-in-graphql-part-2-c6441bcc4302). #130 deals with Authentication and NOT authorization. We certainly need additional work to implement Authorization. Also implementing Authentication in graphql is evaluated in the posts above where it can either be passed as JWT token or handled in graphql layer itself (with its own downsides). Another one is that for a given use case you might not want to expose your schema to the outside world using graphiqL (if by default users are authenticated to access endpoint but not authorized to access resources).

Regarding your observations - "If you put an authorizer on it then the entire GraphQL API ceases to be publicly available which is a problem if you want to allow self registration, login, password reset or other functionality for anonymous users while restricting other operations/information." I would say yes but again it depends on the use cases we are dealing with. For instance, in internal use cases where authorization/signup is handled in a separate layer which makes API call to graphql there might be no signups etc. In other cases Cognito can sign up the user and add him/her to the user pool along with different use cases https://github.com/aws/amazon-cognito-identity-js but it could very well be handled at the resolver layer. We need to think more! but yeah I guess this is just a beginning of a good discussion.