[13.x] Add new EnsureClientIsResourceOwner middleware

[hafezdivandari]

This PR does:

• Fixes Client credentials are not secure for documented use case #691 by adding new EnsureClientIsResourceOwner middleware to make sure the token is a client_credentials token, as this comment asks for.
• Merge the CheckForAnyScope middleware into CheckTokenForAnyScope middleware, as they have the same functionality.
• Merge the CheckScopes middleware into CheckToken middleware, as they have the same functionality.
• Improve the ValidateToken abstract class to be used for any other custom usages the developers may need.
• Add Feature tests for 'Client Credentials" grant.

Summary

• CheckScopes -> CheckToken
• CheckForAnyScope -> CheckTokenForAnyScope
• New EnsureClientIsResourceOwner

Usage

Refer to the updated docs.

Example

You may define middleware aliases in your application's bootstrap/app.php file:

use Laravel\Passport\Http\Middleware\CheckClientCredentials;
 
->withMiddleware(function (Middleware $middleware) {
    $middleware->alias([
        'token' => CheckToken::class,
        'scopes' => CheckToken::class,
        'scope' => CheckTokenForAnyScope::class,
        'client' => EnsureClientIsResourceOwner::class,
    ]);
})

And use them like:

Route::get('/orders', function (Request $request) {
    // Access token is valid...
})->middleware('token');

Route::get('/orders', function (Request $request) {
    // Access token is valid and has both "check-status" and "place-orders" scopes...
})->middleware('token:check-status,place-orders');

Route::get('/orders', function (Request $request) {
    // Access token is valid and has both "check-status" and "place-orders" scopes...
})->middleware('scopes:check-status,place-orders');

Route::get('/orders', function (Request $request) {
    // Access token is valid and has either "check-status" or "place-orders" scope...
})->middleware('scope:check-status,place-orders');

Route::get('/orders', function (Request $request) {
    // Access token is valid and the client is the resource owner (`client_credentials` grant type)...
})->middleware('client');

Route::get('/orders', function (Request $request) {
    // Access token is valid, the client is the resource owner, and has both "check-status" and "place-orders" scopes...
})->middleware('client:check-status,place-orders');

Route::get('/orders', function (Request $request) {
    // Access token is valid, the client is the resource owner, and has both "check-status" and "place-orders" scopes...
})->middleware(['client', 'scopes:check-status,place-orders']);

Route::get('/orders', function (Request $request) {
    // Access token is valid, the client is the resource owner, and has either "check-status" or "place-orders" scopes...
})->middleware(['client', 'scope:check-status,place-orders']);

Route::get('/orders', function () {
    // The user is authenticated and has both "check-status" and "place-orders" scopes...
})->middleware(['auth:api', 'scopes:check-status,place-orders']);

Route::get('/orders', function () {
    // The user is authenticated and has either "check-status" or "place-orders" scope...
})->middleware(['auth:api', 'scope:check-status,place-orders']);

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[taylorotwell]

What does ensuring the client is the resource owner actually mean / do? What resource?

[hafezdivandari]

@taylorotwell the "resource" is protected by the token. This new middleware ensures that the resource owner is an OAuth client itself and not any user with valid token. When issuing an access token using "Client Credentials" grant, the oauth_client_id (JWT's aud) is the same as oauth_user_id (JWT's jti) unlike any other grants. Refer to RFC 6749 section 1.3.4:

The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server. Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.