Register Authentication strategy in graphql

[dineshkuncham7]

In Loopback rest we can register authentication strategy with 'registerAuthenticationStrategy' from @loopback/authentication, similarly how can we do it for graphql resolvers?

[mrmodise]

@dineshkuncham7 I suppose you are using @loopback/graphql if yes then you can do something like this on your application.ts

this.bind(GraphQLBindings.GRAPHQL_AUTH_CHECKER).to(
      async (resolverData: any) => {
       // get your request object
        const Request = resolverData?.context?.req;
       // bind it
        this.bind(RestBindings.Http.REQUEST).to(Request);
        // get your service to do authentication
        const jwtService = await this.get<JwtService>(
          ServiceBindings.JWT_SERVICE.key,
        );
       // end result would be a boolean. 
        return jwtService.authenticate(resolverData?.context?.req?.headers);
      },
    );

and enforce security in your resolvers like:

@authorized() // this would trigger authorization
  @query(() => Recipes, {nullable: true})
  async recipes() {
}

[mrmodise]

For that you will have to write something up similar to the REST alternative unfortunately

[dineshkuncham7]

I am trying to do that but don't know where to start, can you please point me to some example or starting position for this?

[mschnee]

I am currently using the following to allow @inject(SecurityBindings.USER) to be functional:

    this.bind(GraphQLBindings.GRAPHQL_CONTEXT_RESOLVER).to(async (graphQLCtx: ExpressContext) => {
      const reqCtx = graphQLCtx.req[MIDDLEWARE_CONTEXT];
      if (graphQLCtx.req.headers?.authorization?.startsWith('Bearer ')) {
        const token = graphQLCtx.req.headers.authorization.replace('Bearer ', '');
        const currentUser = verifyToken(graphQLCtx.req, token, JWT_SECRET);
        reqCtx?.bind(SecurityBindings.USER).to(currentUser);
      }

      return graphQLCtx;
    });

A couple of points to note:

• This is based, underneath, on a set of libraries we use where the loopback auth strategy/decorators are just sugar on top of an auth system. The function verifyToken is responsible fort handling that: our implementation does NOT look like the reference @loopback/authentication examples.
• Binding the currentUser is optional. This is required if you want to support any kind of playground or federation or basic schema lookup. TLDR: do not throw an error here.
• an @inject.setter() should probably be used instead 🤷‍♂️

The auth strategy could/should be available here, however some work would need to be done in order to support adding @authenticate to a Resolver class/methods.

[mrmodise]

Thanks. Sounds like you have something place perhaps do a PR and we can all look at whats possible?

[dineshkuncham7]

I do have similar strategy in my application

this.bind(GraphQLBindings.GRAPHQL_CONTEXT_RESOLVER).to(context => {
      const basicAuthService = new BasicAuthService();
      const userProfile: CustomUserProfile = basicAuthService.getUserProfile(
        context.req,
      );
      return {...context, userProfile};
    });

• 'getUserProfile' method return userProfile from token

• In resolvers class I am accessing the profile via GraphQL Bindings like below

@resolver(() => User)
export class UserResolver {
  constructor(
    // constructor injection of repository
    @repository(UserRepository)
    private readonly userRepo: UserRepository,
    // It's possible to inject the resolver data
    @inject(GraphQLBindings.RESOLVER_DATA)
    private resolverData: ResolverData<CustomGraphQLContext>,
  ) {}

@mutation(() => [User])
  @authorized(USER_ROLES.admin)
  async addUser(
    @arg('user') user: UserInput,
  ): Promise<UpcomingDeliveries[]> {
    logger.info(`adding new user`);
    const {
      user: {name: username},
    } = this.resolverData.context.userProfile;
    return this.userRepo.createAllWrapper(
      user,
      username,
    );
  }
}

• The problem with doing it in context resolver is it executes for every request (even for IntrospectionQuery during development), if we don't want authentication for a particular query it is not possible or ideal. I am hoping for something like @authenticate decorator we can use on resolver class or query level.