Vue SPA с паспортом Laravel 6

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

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

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

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

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

Запрос на авторизацию

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

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

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

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


person Thomas    schedule 12.02.2020    source источник


Ответы (1)


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

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

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

Как вы сказали, неявные токены предоставления больше не рекомендуются (RFC 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);
    }
}

Приложение \ Паспорт \ Модели \ PkceClient:

<?php
namespace App\Passport\Models;

use Laravel\Passport\Client as BaseClient;

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

В качестве примечания следует указать, что диалоговое окно не следует пропускать для клиентов, которым не доверяют в соответствии с RFC 8252 8.6

8.6. Выдача себя за клиента

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

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

person Albin N    schedule 26.02.2020
comment
вот PR-ссылка этой функции: github.com/laravel/passport/pull/1022 - person Buraco; 25.10.2020