Closes: https://github.com/mercurius-js/auth/issues/1

PR so you can follow my progress as I head towards shipping v1.0 :)

Still todo:

• [x] Add Application Lifecycle hook to Mercurius
• [x] Make auth directive configurable
• [x] Go over validation options and add more tests for these
• [x] Define symbols for internals
• [x] Use resolver overrides
• [x] More tests for the gateway
• [x] General tidy up of codebase
• [x] Set custom auth errors
• [x] Improve performance (using current Benchmarks with and without Auth as a reference)
• [x] Docs
• [x] Examples

Implements #43

I'm creating this draft PR to get some feedback about this implementation.

How it works

Every directive adds a preExecution hook. The hook will:

• understand if the input query is an introspection
• if an introspection query is found:
  • it executes the directive's applyPolicy for every FIELDS the directive is attached to
  • the applyPolicy function runs without the parent object and the input arguments (it should be fine)
  • based on the applyPolicy result, the hook filters the GraphQLSchema object by filtering the FIELDS or OBJECTS associated with the directive itself
• the hook will return the filtered schema to the next preExecution function

Note that understanding if the query is an introspection one is necessary or the authorization errors will no more be visible.

Example:

• read an @auth Query
• the filter hook will understand that the user is not authenticated executing the applyPolicy function
• the @auth FIELD are evicted from the schema
• the query is executed against the filtered schema, so the directive's fields are no more in the schema, and they cannot trigger the auth error
• the output for those fields will be null without the corresponding error.

Todos

I think this PR requires many optimizations:

• [x] improve the isIntrospection function
• [x] execute the isIntrospection once (now it is executed one time for each directive)
• [x] how could we run the wrapSchema filtering function once instead of one time for each directive. The main issue here is that the plugin is registered multiple times
• [x] applyPolicy memoization. it cannot be executed once due different parameters. Example @hasRole(role: "admin") vs @hasRole(role: "reader")
• [x] how to handle multiple queries into one request. EDIT: one inspection query triggers the filtering
• [ ] documentation

Let me know your thought

Hi guys, How I can set custom directives to the current field through Javascript code?

I created a custom Directive:

const authDirective = new GraphQLDirective({
    name: 'auth',
    locations: [DirectiveLocation.OBJECT, DirectiveLocation.FIELD_DEFINITION],
    args: ...
})

Added to the schema:

const schema = new GraphQLSchema({
    directives: [authDirective],
    query: new GraphQLObjectType({
        fields: {
            secretData: ...
        }
    })
})

How I can use my directive only for the secretData field?

I tried to add a directives parameter for field definition but it doesn't work:

{
    type: validateWidgetQLType,
    args: validateWidgetQLArgs,
    directives: [
        { name: 'auth', arguments: { requires: 0 }}
    ],
}

Please help!

Hello everyone!

When this plugin returns an error, of any type, it uses HTTP 500 as status code. In this case Apollo (for Angular) treat it as networkError instead of graphQlErrors, making it difficult to handle. I'm doing something wrong?

I have multiple federated services, and each schema looks similar to the following:

directive @auth(requires: String!) on OBJECT | FIELD_DEFINITION
extend type Query {
  """
  Provide information about an account's balances
  """
  inqAcctAvail(
    clientId: Int!
    acctId: String!
    suffix: Int
  ): AcctAvail @auth(requires: "inqAcctAvail")
}

type AcctAvail @auth(requires: "inqAcctAvail") @key(fields: "clientId acctId suffix") {
  clientId: Int
  acctId: String
  suffix: Int

  """
  Available money from AAS realtime auth system
  """
  availMoney: Float

  """
  Available cash from AAS realtime auth system
  """
  availCash: Float
}

My auth function looks like so:

app.register(mercuriusAuth, {
    authContext(context) {
      const {
        reply: {
          request: {
            headers,
          },
        },
      } = context;
      if (headers.introspect === 'true') {
        return {};
      }
      if (!headers['gql-auth']) {
        throw new Error('Not authorized');
      }
      return {
        identity: JSON.parse(context.reply.request.headers['gql-auth']),
      };
    },
    async applyPolicy(
      authDirectiveAST,
      source,
      { clientId: argClientId },
      {
        auth: {
          identity,
        },
      },
    ) {
      const findArg = (arg, ast) => {
        let result;
        ast.arguments.forEach((a) => {
          if (a.kind === 'Argument'
            && a.name.value === arg) {
            result = a.value.value;
          }
        });
        return result;
      };
      const requires = findArg('requires', authDirectiveAST);
      let srcClientId;
      if (source) {
        srcClientId = source.clientId;
      }
      const clientId = argClientId || srcClientId;
      if (!requires
        || (
          process.env.NODE_ENV !== 'production'
          && identity.roles.includes(':admin')
        )) {
        return true;
      }
      if (!identity.roles.includes(`${pad(clientId, 4)}:${requires}`)) {
        throw new Error('User does not have access');
      }
      return true;
    },
    authDirective: 'auth',
  });

When testing my inqAcctAvail query, the auth works perfectly. However when testing the AcctAvail type through an entity call, the applyPolicy is not being triggered through my test, thus it is failing.

Test:

test('should throw error, entity not authorized', async (t) => {
  const variables = {
    representations: [
      {
        __typename: 'AcctAvail',
        clientId: 5555,
        acctId: '10000000001',
        suffix: 0,
      },
    ],
  };
  const query = '
      query EntitiesQuery($representations: [_Any!]!) {
        _entities(representations: $representations) {
          __typename
          ... on AcctAvail {
            clientId
            suffix
            acctId
          }
        }
      }';
  const res = await app.inject({
    method: 'POST',
    url: '/graphql',
    body: {
      query,
      variables,
    },
    headers: {
      'gql-auth': JSON.stringify({
        roles: ['9999:fail'],
      }),
    },
  });
  const response = JSON.parse(res.body);
  t.equal(response.errors ? response.errors[0] : null, 'User does not have access');
  t.end();
});

Noticed the failing tests when fixing this PR: https://github.com/mercurius-js/auth/pull/73 and found that upon a fresh npm install, some tests fail in the test file: test/introspection-filter-basics.js. One example failure is as follows:

No idea indication as to why yet but I suspect a downstream module has updated it's behaviour. Will document findings in this issue before moving to a fix :)

It would be great to support multiple directives:

• @hasRole
• @hasPermission

Example:

type Article {
  id: ID!
  title: String!
  content: String! @hasPermission(resources: ["subscribed"])
}

type Query {
  listArticles: [Article]!
}

type Mutation {
  publishArticle(articleId: ID!): Article! @hasRole(role: "editor")
  unpublishArticle(articleId: ID!):Boolean @hasPermission(resources: ["publish","delete"])
}

Doing so, it should be open to integrating external Identity Management such as:

• keycloak
• Auth0 Authorization extension
• any Identity Manager that implements the User -> Role -> Permission paradigm

When dealing with federation, the resolveReference function was not getting wrapped, thus was running even if the auth failed. the field resolvers would still fail, but no need to run field resolvers if type resolveRefence auth check failed

Hi, thanks again for setting this repo up - really appreciate it! :) I've got a fair bit of boilerplate code to push up so we should have everything required straight away and I have also made a start on the core functionality. Before I commit anything to the repo, I just wanted to double check what your preference is regarding the commit + review process for a pre-release repo like this?

Here's my initial plan in chronological order to get the first release ready:

• Get plumbing code in (it's pretty much ready to go now)
• Core functionality for the auth plugin with 100% test coverage
• Examples
• Documentation
• Typings
• Release package

Bumps mercurius from 8.12.0 to 9.1.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Right now, setting the directive schema as following, it returns the information to all the clients:

directive @auth(
  requires: Role = ADMIN,
) on OBJECT | FIELD_DEFINITION

enum Role {
  ADMIN
  REVIEWER
  USER
  UNKNOWN
}

type Query {
  add(x: Int, y: Int): Int @auth(requires: ADMIN) 
}

Then running the query:

{
  __schema {
    queryType {
      fields {
        name
      }
    }
  }
}

Returns the meta-fields

{
  "data": {
    "__schema": {
      "queryType": {
        "fields": [
          {
            "name": "add"
          }
        ]
      }
    }
  }
}

Hasura applies a different technique: it returns only the schema that applies its rules.

So, using this logic to the @auth directive, we could filter the returned GraphQL schema. The user's client will see only those query and field it should see.

This requires that the user adds to the client additional information (such as an auth token) to get access to all the GraphQL Schema and documentation.

Bumps @sinonjs/fake-timers from 9.1.2 to 10.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

We should take a look at the Mercurius Auth documentation to make sure it is super clear for new and existing users. We should also make sure it provides everything a developer needs to use and understand Mercurius Auth (without having to look closer at the underlying code/tests for example). Before starting an implementation, it would be great to understand the following:

• Does the docs structure make sense? What could be improved?
• Is the README sufficient? Is it missing any key information?
• Do we want a best practices/examples section?
• Anything else that is missing or think should be included?

Keen to hear everyone's thoughts on this!