The method that an application uses to identify every single user of the application is ACL. This is the system that informs the application what access rights or permissions a user or group of users have for a specific task or action.

Every task (function or action) has an attribute to identify which users can use it, and ACL is a list that links every task with every action, such as read, write, or execute.

ACL has the following two featured advantages for the applications that use it:

For our application based on microservices, we recommend having a different ACL for each microservice; this avoids having a single point of entry for the entire application. Remember that we are building microservices, and one of the requirements was that microservices should be isolated and independent; so, having a microservice to control the rest of them is not a good practice.

This is not a difficult task, it makes sense because every microservice should have different tasks and every task is different for each user in terms of permissions. Imagine that we have a user who has the following permissions. This user can create secrets and check the nearby secrets, but is not allowed to create battles or new users. Managing the ACL globally will be a problem in terms of scalability when a new microservice is added to the system or even when new developers join the team and they have to understand the complex system of global ACL. As you can see, it is better to have an ACL system for each microservice, so when you add a new one, it is not necessary to modify the ACL for the rest.

Lumen provides us with an authentication process in order to get a user to sign up, log in, log out, and reset the password, and it also provides an ACL system whose classes are called Gate.

Gate allows us to know whether a specific user has permissions to do a specific action. This is very easy and it can be used in every method of your API.

To set up ACL on Lumen, you have to enable facades on your bootstrap/app.php by removing the semicolon from the app->withFacades(); line; if this line does not appear on your file, add it.

It is also necessary to create a new file on config/Auth.php with the following code:

    <?php
      return [
        'defaults' => [
          'guard' => env('AUTH_GUARD', 'api'),
        ],
        'guards' => [
          'api' => [
            'driver' => 'token',
            'provider' => 'users'
          ],
        ],
        'providers' => [
          'users' => [
            'driver' => 'eloquent',
            // We should get model name from JWT configuration
            'model' => app('config')->get('jwt.user'),
          ],
        ],
      ];

The preceding code is necessary to use the Gate class on our controller in order to check the user permissions.

Once this is set up, we have to define the different actions or situations available for a specific user. To do this, open the app/Providers/AuthServiceProvider.php file; on the boot() function, we can define every action or situation by writing the following code:

    <?php
      /* Code Omitted */
      use IlluminateContractsAuthAccessGate;
      class AuthServiceProvider extends ServiceProvider
      {
        /* Code Omitted */
        public function boot()
        {
          Gate::define('update-profile', function ($user, $profile) {
            return $user->id === $profile->user_id;
          });
        }

Once we have defined the situation, we can put it into our function. There are three different ways to use it: allows, checks and denies. The first two are the same, they return true when the defined situation returns true, and the last one returns true when the defined situation returns false:

    if (Gate::allows('update-profile', $profile)) {
      // The current user can update their profile...
    }
    if (Gate::denies('update-profile', $profile)) {
      // The current user can't update their profile...
    }

As you can see, it is not necessary to send the $user variable, it will get the current user automatically.