Vue СПА с Laravel 6 паспортом

Question

Справочная информация. Единственный опыт, с которым я сталкиваюсь при аутентификации, - это обычные логины на основе форм, типичное имя пользователя и пароль для контроллера с перенаправлением или использования JWT с обычным входом в систему. Я хотел бы использовать Laravel Паспорт для достижения той же цели.

Мне нужно создать приложение SAAS, используя Vue с Laravel Паспортом (Laravel 6x с Din go API).

Приложение должно быть многопользовательским с ролями и разрешениями.

Я читал, что лучшая методология - это использовать «Предоставление кода авторизации с PKCE» для SPA .

Проблема, с которой я столкнулся, состоит в том, что мое приложение Vue устанавливает вызов кода и т.д. c. Запрашивает код авторизации, затем перенаправляется на страницу входа Laravel, но как только я вхожу, я получаю следующий экран:

Есть ли способ обойти это? (Я пытался использовать пользовательский клиент с skipsAuthorization, но, похоже, это не сработало) Использую ли я правильный поток OAuth?

В документации Laravel Passport есть следующее:

Клиент для предоставления пароля: для этого требуется секрет, поэтому я не понимаю, как я могу это использовать? Неявные жетоны предоставления: теперь не рекомендуется и не должны использоваться.

, который оставляет только жетоны личного доступа. Но правильный ли это «поток» для использования?

Answer 1

PKCE следует использовать в соответствии с RF C 8252 . Я полагаю, что отдельное publi c SPA можно рассматривать в тех же терминах, что и нативное приложение, поскольку нет способа хранить секрет клиента.

В разделе 6 требуется, чтобы и клиенты, и серверы использовали PKCE для собственных клиентов приложения Publi c. Серверы авторизации ДОЛЖНЫ отклонять
запросы авторизации от собственных приложений, которые не используют PKCE, путем
возврата сообщения об ошибке, как определено в разделе 4.4.1 PKCE
[RFC7636].

Я прочитал RF C выше, и это помогло мне обернуть голову вокруг него. Я думаю, что документирование для PKCE в Laravel документах немного странно (например, для клиента PHP).

Как вы сказали, токены с неявным предоставлением больше не рекомендуются ( RF C 8252 # 8.3 ):

Поток авторизации неявного предоставления OAuth 2.0 (определенный в
Раздел 4.2 OAuth 2.0 [RFC6749]) обычно работает с практикой выполнения авторизации запросить в браузере и получить
ответ об авторизации посредством связи между приложениями на основе URI.
Однако, поскольку неявный поток не может быть защищен PKCE [RFC7636]
(что требуется в разделе 8.1), использование неявного потока с собственными приложениями НЕ РЕКОМЕНДУЕТСЯ.

Я настроил SPA с работающим потоком PKCE. Я создал новую модель клиента, которую затем использую, чтобы пропустить упомянутое выше диалоговое окно.

AuthServiceProvider:

<?php
namespace App\Providers;

use App\Passport\Models\PkceClient;
use Laravel\Passport\Passport;
use Illuminate\Support\Facades\Gate;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;

class AuthServiceProvider extends ServiceProvider
{
    /**
     * The policy mappings for the application.
     *
     * @var array
     */
    protected $policies = [
        'App\Model' => 'App\Policies\ModelPolicy',
    ];

    /**
     * Register any authentication / authorization services.
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();

        Passport::routes();
        Passport::useClientModel(PkceClient::class);
    }
}

App \ Passport \ Models \ PkceClient:

<?php
namespace App\Passport\Models;

use Laravel\Passport\Client as BaseClient;

class PkceClient extends BaseClient
{
    public function skipsAuthorization()
    {
        return $this->firstParty();
    }
}

В качестве идентификатора следует указать, что диалоговое окно не должно быть пропущено для клиентов, которым не доверяют в соответствии с RF C 8252 8,6

8,6. Олицетворение клиента

Как указано в разделе 10.2 OAuth 2.0 [RFC6749], серверу авторизации НЕ СЛЕДУЕТ обрабатывать запросы авторизации автоматически
без согласия пользователя или взаимодействия, за исключением случаев, когда может быть идентифицирован клиент
. уверенный. Это включает в себя случай, когда пользователь
ранее одобрил запрос на авторизацию для данного идентификатора клиента - если личность клиента не может быть подтверждена, запрос ДОЛЖЕН
обрабатываться так, как если бы предыдущий запрос не был утвержден.

Такие меры, как заявленные перенаправления схемы «https», МОГУТ быть приняты серверами авторизации в качестве подтверждения личности. Некоторые операционные системы могут предлагать альтернативные специфичные для платформы c идентификационные функции, которые МОГУТ быть приняты соответствующим образом.