[13.x] Improve issuing PATs

[hafezdivandari]

This PR improves issuing personal access tokens:

• Reduces number of queries to retrieve the client from the DB from 3 to 1.
• Removes the necessity of redeclaring client credentials on passport.personal_access_client config property and environment variables for each user provider.
• Reorganizes personal access grant feature tests.
• Fully backward compatible and no upgrading steps is needed.

Before

After

Create a client using passport:client --personal for each user provider. Set client credentials on passport.personal_access_token config property for each user provider. Issue access token using $user->createToken(). Get client credentials for the given user provider from config. Retrieve the client from DB and validate provider. Pass client_id, client_secret and user_id to the grant. Retrieve the client from DB to validate the secret. Retrieve the client from DB to issue the token.

Create a client using passport:client --personal for each user provider. Issue access token using $user->createToken(). Pass provider and user_id to the grant. Retrieve the client from DB for the given provider to issue the token.

[autaut03]

@hafezdivandari Hey. This PR essentially removed the ability of passing in a custom client_id to the personal_access grant, which is useful when an application has multiple personal access clients. In our case, there's one that manages user-created access tokens, and another that's used for the login flow.

Was this removal really necessary? It was even suggested before that createToken accepts an optional $clientId, so there's definitely at least a couple of us that would like that sort of functionality, and this PR further distances us from that.

[hafezdivandari]

@autaut03 the ability is not removed, it's actually much simpler to use now. If you have multiple personal access clients for different user providers, Passport now automatically choose the right client (based on user provider) when creating a PAT.

You may refer to the tests here for some sample usage: https://github.com/laravel/passport/blob/13.x/tests/Feature/PersonalAccessGrantTest.php

[autaut03]

@hafezdivandari The provider is the same. Only the clients differ - to be able to separate system-generated and user-created tokens when displaying them to the user.

E.g. a user creates a token (POST /personal-access-tokens, client_id = 1) and sees it in the list of their tokens (GET /personal-access-tokens, client_id = 1). Then the system creates a token using the personal_access grant for a different purpose (in our case - temporary access token for 2fa) with a different client_id = 2.

By separating the clients, we can still display only the user-created tokens to the user, and exclude ones created internally by the system. The user provider in both cases is the same and completely irrelevant.

[hafezdivandari]

@autaut03 It's really strange (non-standard IMHO) use case, because normally there shouldn't be any "system-generated PATs", but if you want to do this for whatever reason, you are able to customize the Laravel\Passport\ClientRepository class and override the personalAccessClient method. Something like the following code:

namespace App\Repositories;

class ClientRepository extends \Laravel\Passport\ClientRepository
{
    #[\Override]
    public function personalAccessClient(string $provider): Client
    {
        // return your client...
    }
}

// Then in you app service provider....
$this->app->when(\Laravel\Passport\Bridge\PersonalAccessGrant::class)
            ->needs(\Laravel\Passport\ClientRepository::class)
            ->give(fn () => new \App\Repositories\ClientRepository);