Использование промежуточного программного обеспечения учетных данных клиента для всех запросов API

В моем файле routes/api.php у меня есть такая группа маршрутов:

Route::group([
    'prefix' => config('api.route_prefix'),
    'middleware' => ['api', 'auth:api'],
], function() {
// ...

Это правильно разрешает только пользователям с токенами, полученными с помощью пароля, предоставлять доступ к этим маршрутам. При попытке реализовать предоставление учетных данных клиента я обнаружил, что необходимо отдельное промежуточное ПО. . Поскольку промежуточное ПО auth:api вызывает исключение, возникает конфликт, потому что я хочу, чтобы запросы с действительными токенами любого типа гранта обращались к этим маршрутам.

Я обнаружил, что использование только промежуточного программного обеспечения учетных данных клиента, кажется, проверяет оба, но я не уверен, есть ли какие-либо плохие последствия этого.

Что плохого в том, чтобы обойти промежуточное ПО auth:api и заменить его на Laravel\Passport\Http\Middleware\CheckClientCredentials?


laravel authorization oauth-2.0 laravel-passport
person Jeff Lambert    schedule 06.12.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Одним очевидным большим недостатком является то, что учетные данные клиента, похоже, не содержат никакой информации о пользователе в токене JWT. Это приводит к тому, что пользовательский преобразователь для запроса возвращает null для вызовов request()->user(). От Laravel\Passport\Guards\TokenGuard::authenticateViaBearerToken это возвращало null:

// If the access token is valid we will retrieve the user according to the user ID
// associated with the token. We will use the provider implementation which may
// be used to retrieve users from Eloquent. Next, we'll be ready to continue.
$user = $this->provider->retrieveById(
    $psr->getAttribute('oauth_user_id')
);

Отслеживание $psr->getAttribute привело меня к League\OAuth2\Server\AuthorizationValidators\BearerTokenValidator::validateAuthorization:

 // Return the request with additional attributes
return $request
    ->withAttribute('oauth_access_token_id', $token->getClaim('jti'))
    ->withAttribute('oauth_client_id', $token->getClaim('aud'))
    ->withAttribute('oauth_user_id', $token->getClaim('sub'))
    ->withAttribute('oauth_scopes', $token->getClaim('scopes'));

Все атрибуты, кроме oauth_user_id, устанавливались правильно через утверждения токена, $token в моем случае является экземпляром Lcobucci\JWT\Token. Таким образом, использование только промежуточного программного обеспечения учетных данных клиента не является хорошим решением для наличия единого набора маршрутов, даже если используется клиент oauth с указанным user_id.

person Jeff Lambert    schedule 13.12.2017
comment
FWIW я смог обойти это, подклассировав League\OAuth2\Server\Grant\AbstractGrant и поставщика услуг Passports для регистрации моего ClientCredentialsGrant вместо League, вот суть, хотя это ограничивает меня в отношении любых обновлений исходного кода. - person Jeff Lambert; 26.04.2018