Laravel Passport good practices for issuing multiple tokens

Question

I have a question about Laravel Passport and the best way to manage api access_tokens.

Currently we have:

• A token issued by a grant_type: password and with no scope:

    $data = [
         'grant_type' => 'password',
         'client_id' => $client_id,
         'client_secret' => $client_secret,
         'username' => $user->email,
         'password' => $user->password,
         'scope' => '',
     ];
  

• A token for only view a picture of a user by creating it like that:

  $token = $user->createToken('User Picture token', ['view-picture'])->accessToken;
  

The first token issued by the grant_type: password will be used only for getting personal user informations.

Does is it a good practice?

We want to restrict access to a resource as follows: A "message" resource that contains CRUD actions to its access token with a specific scope.

So we want each resource protected by a different token and a different scope.

Does the personal access_token are made for?

EDIT 1:

In order to manage user permissions we use Gates & Policies from Laravel.

Answer 1

Laravel Passport gives you the ability to implemente a full Oauth2 server in a matter of minutes. This means, you can mount a full server to not only manage access to your own apps but for third-party applications.

When I said "your own apps" I mean the ones developed by you and/or your team. By "third-party apps" I mean the ones that are developed by other developers that have access to your API. Token scopes are a good way to limit the actions this third-party apps can do on behalf of your users.

Take Facebook as an example. If you want to implement access in your app through Facebook, your users will need to allow your app to access to their profile data in order to retrieve their details to effectively log-in in your system.

From the Passport documentation:

Token Scopes

Scopes allow your API clients to request a specific set of permissions when requesting authorization to access an account. For example, if you are building an e-commerce application, not all API consumers will need the ability to place orders. Instead, you may allow the consumers to only request authorization to access order shipment statuses. In other words, scopes allow your application's users to limit the actions a third-party application can perform on their behalf.

Now, if your API is gonna be consumed just by your apps, I mean, if you are not going to expose or make public your API blueprint to anyone but your team, you can just authorize users with roles and permissions and/or implement Laravel Gates/Policies.

Then you can just identify the user by the token and check if the user has the right permission/role to make a specific action or access to some data (or parts of it).