1

背景：我在身份验证方面的唯一经验是普通的基于表单的登录、典型的用户名和通过重定向或使用 JWT 进行常规登录的控制器的密码。我想使用 Laravel Passport 来实现同样的目标。

我需要使用带有 Laravel Passport 的 Vue（带有 Dingo API 的 Laravel 6x）创建一个 SAAS 应用程序。

该应用程序需要是具有角色和权限的多用户。

我读过最好的方法是对 SPA 使用“带有 PKCE 的授权代码授予”。

我遇到的问题是我的 Vue 应用程序设置了代码质询等。请求授权码，然后被定向到 Laravel 登录页面，但是一旦我登录，我就会得到以下屏幕：

授权请求

有没有办法绕过这个？（我尝试使用带有 skipsAuthorization 的自定义客户端，但这似乎不起作用）我使用的是正确的 OAuth 流程吗？

在 Laravel Passport 文档中，有以下内容：

密码授予客户端：虽然这需要一个秘密，所以我不知道如何使用它？隐式授予令牌：现在不鼓励使用，不应使用。

只留下个人访问令牌。但这是正确的“流程”吗？

4

1 回答 1

3

PKCE 应根据RFC 8252使用。我想独立的公共 SPA 可以被视为与原生应用程序相同的术语，因为无法存储客户端机密。

第 6 节要求客户端和服务器都将 PKCE 用于公共本机应用程序客户端。授权服务器应该通过 返回错误消息来拒绝
来自不使用 PKCE 的本机应用程序的授权请求，如 PKCE [RFC7636] 的第 4.4.1 节中所定义。

我已经阅读了上面的 RFC，它帮助我理解了它。我认为 Laravel 文档中 PKCE 的文档有点奇怪（例如假设一个 PHP 客户端）。

正如您所说，不再建议使用隐式授权令牌（RFC 8252 #8.3）：

OAuth 2.0 隐式授予授权流程（在
OAuth 2.0 [RFC6749] 的第 4.2 节中定义）通常适用于在浏览器中执行授权请求并
通过基于 URI 的应用间通信接收授权响应的做法。
但是，由于隐式流不能被 PKCE [RFC7636]
（第 8.1 节要求）保护，因此不建议将隐式流与本机应用程序一起使用。

我已经设置了一个带有工作 PKCE 流的 SPA。我创建了一个新的客户端模型，然后我用它来跳过您上面提到的对话框。

身份验证服务提供者：

<?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. 客户模拟

如 OAuth 2.0 [RFC6749] 的第 10.2 节所述，授权服务器不应该在
没有用户同意或交互的情况下自动处理授权请求，除非
可以确保客户端的身份。这包括用户
先前已批准给定客户端 id 的授权请求的情况——除非可以证明客户端的身份，否则该请求应该
被处理，就好像先前的请求没有被批准一样。

授权服务器可以接受诸如声称的“https”方案重定向之类的措施作为身份证明。某些操作系统可能会提供可能被接受的替代平台特定身份特征，视情况而定。

于 2020-02-26T07:15:05.400 回答