Authentication

Introduction

Online ordering is all the rage right now, as customers look to beat the lines by placing an order online and picking it up shortly afterward. The (theoretical) mobile team has been hard at work on a mobile application that customers can use to place orders from the comfort of their homes. We need to provide a way to do this securely.

So far, when we’ve been responding to API requests, we haven’t been concerned with who is making those requests. We’ve only focused on dealing with the data itself. Both menu updates and the orders themselves have come from within the restaurant, so we could just accept whatever it sent us. If we’re going to accept orders from the customers themselves, however, not only do we need to keep track of who has ordered what, but we also need to give each customer the ability to view and subscribe to their orders.

User authentication

Tracking customers also entails tracking employees because we need a way to permit employees to carry out forbidden actions, like editing the menu or completing an order. Most of the operations in the system at the moment ought only to be carried out by employees. The first step then is being able to identify whether someone is an employee or a customer. From there, we’ll see how we can use this information to perform authentication and authorization checks within our schema.

Our goal is to support a simple mutation like the following: