Vue SPA with Laravel 6 Passport - vuejs2

Question

Background: The only experience I have with authentication are normal form-based logins, the typical username, and password to a controller with a redirect or using JWT with a regular login. I would like to use Laravel Passport to achieve the same thing.
I need to create a SAAS app using Vue with Laravel Passport (Laravel 6x with Dingo API).
The app needs to be multi-user with roles and permissions.
I've read that the best methodology is to use the "Authorization Code Grant with PKCE" for a SPA.
The problem that I've run into is that my Vue app sets up the code challenge etc. Requests the authorization code, then gets directed to the Laravel log in page, but as soon as I log in, I get the following screen:
Is there any way to bypass this? (I tried using a custom client with skipsAuthorization, but that doesn't seem to work)
Am I using the correct OAuth flow?
In the Laravel Passport documentation, there are the following:
Password Grant Client: This requires a secret though, so I don't see how I can use this?
Implicit Grant Tokens: This is now discouraged and should not be used.
Which only leaves Personal Access Tokens. But is that the correct "flow" to use?

Answer 1

PKCE should be used according to RFC 8252. I guess a stand alone public SPA can be considered in the same terms as a native app, in that there is no way to store a client secret.
Section 6 requires that both clients and servers use PKCE for public
native app clients. Authorization servers SHOULD reject
authorization requests from native apps that don't use PKCE by
returning an error message, as defined in Section 4.4.1 of PKCE
[RFC7636].
I've read the RFC above and it helped me wrap my head around it. I think the documnetation for PKCE in the Laravel docs are a bit strange (assuming a PHP client for example).
As you said, implicit grant tokens is not recommended anymore (RFC 8252 #8.3):
The OAuth 2.0 implicit grant authorization flow (defined in
Section 4.2 of OAuth 2.0 [RFC6749]) generally works with the practice
of performing the authorization request in the browser and receiving
the authorization response via URI-based inter-app communication.
However, as the implicit flow cannot be protected by PKCE [RFC7636]
(which is required in Section 8.1), the use of the Implicit Flow with
native apps is NOT RECOMMENDED.
I've setup a SPA with a working PKCE-flow. I created a new client model which I then use to skip the dialog you mentioned above.
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();
}
}
As a sidenote it should be stated that the dialog should not be skipped for clients that is not trusted according to the RFC 8252 8.6
8.6. Client Impersonation
As stated in Section 10.2 of OAuth 2.0 [RFC6749], the authorization
server SHOULD NOT process authorization requests automatically
without user consent or interaction, except when the identity of the
client can be assured. This includes the case where the user has
previously approved an authorization request for a given client id --
unless the identity of the client can be proven, the request SHOULD
be processed as if no previous request had been approved.
Measures such as claimed "https" scheme redirects MAY be accepted
by authorization servers as identity proof. Some operating systems
may offer alternative platform-specific identity features that MAY
be accepted, as appropriate.