Client_ID

[lucasmichot]

It feels a bit strange to get a client ID as the primary key of oauth_clients @taylorotwell Would it not make sense to provide a uuid field for that ?

[heisian]

@baig772 I'm not sure if I would recommend it - it is waaay out of date in comparison w/ the latest passport. At my current company we use node on the backend (which I would steer clear of IMO!), so I haven't been in Laravel land for a while.

@jjoao07 I would highly recommend trying @ssmulders's solution instead. I forget the specifics, but his workaround is better than the one I originally had come up with in my fork.

[billriess]

Will there be an official movement on this? @taylorotwell

[driesvints]

@billriess eventually yeah probably but in the meantime any PRs for this are welcome.

[grEvenX]

@driesvints There was already a PR on this ~2 years ago: https://github.com/laravel/passport/pull/49. There was a comment in this thread that md5 is slow, but since that's only used when actually creating the client, I wouldn't think that it would be a big concern?

Any thoughts on re-opening that PR or use the approach there as a possible solution?

[driesvints]

@grEvenX not sure tbh. Don't have time atm to dig really deep into it.

[billriess]

There is also this one from a while back: https://github.com/laravel/passport/pull/168

[diadal]

Not sure you can try this https://github.com/diadal/passport

[driesvints]

@AmirrezaNasiri this is open source software. If you need this then feel free to put some work into a PR.

[driesvints]

@grEvenX I think if a new PR was attempted with a very good an thorough explanation and tests that it has a chance of being merged in. Best if you targeted master.

I'm planning on doing some Passport work in September after Laracon EU.

[sebastiaanluca]

I'm currently in the process of setting up a Laravel Passport API. Enabling UUIDs was quite trivial given the few blog posts about it, yet having a more difficult experience enabling hashed client secrets. Will share my progress and code once I have it figured out.

One thing I want to note is that you probably want to use UUIDs for your API clients (either by storing incremental IDs in your database and using HashIds or something similar to do dynamic routing or, even better, just use UUIDs in your database). And more importantly, that client secrets should be hashed, not encrypted, just like Laravel hashes user passwords. AFAIK there's no need for the OAuth server to know the actual secret, just verify the request's secret with the one in the database when issuing tokens.

@driesvints I managed to get salted/hashed client secrets working the same way as user passwords when issuing tokens and accessing client credentials protected endpoints.

Just had to setup the correct db field, enable hashing in the client model, and change the following lines in \Laravel\Passport\Bridge\ClientRepository::validateClient():

return ! $record->confidential() || hash_equals($record->secret, (string) $clientSecret);

return ! $record->confidential() || app(Hasher::class)->check((string) $clientSecret, $record->secret);

Apparently all checks (even the ones in the CheckClientCredentials middleware go through this method. Still have to check if I can override the bridge ClientRepository (for now) by overriding the binding.

Going into weekend/holiday mode, but can probably whip up a PR after. Any tips you can give me on creating a PR with higher chances of getting merged? This feature has to be optional, I suppose? Or do you want to enforce security and require hashed client secrets and introduce a breaking change? I'll add as much documentation and tests as I can.

[sebastiaanluca]

Working WIP for hashed client secrets: #1145.

---

Not sure how to go about properly introducing UUIDs in the current setup. It'll either be:

• A breaking change without the option to upgrade (otherwise all existing APIs would have to change their IDs)
• An optional setting for those starting new projects or willing to accept the downside of upgrading existing IDs themselves (using a fresh migration including UUID fields)
• Or a solution that introduces an encrypting/decrypting hashids middleware like discussed to mask the internal database IDs (less desirable since they're not real UUIDs then)

Feedback appreciated.

[sebastiaanluca]

For those interested, the PR to optionally use hashed secrets has been merged: https://github.com/laravel/passport/pull/1145#event-2910811211. Will probably be available in the next (major, minor?) release.

Not planning on doing a PR to introduce UUIDs as I have no answer on the questions above and you can implement this yourself quite easily by extending the client model.

[thamibn]

using uuid i am getting error when i run php artisan passport:install

General error: 1364 Field 'id' doesn't have a default value

even after moding the boot method of AppServiceProvider.php to somethign like this

<?php

namespace App\Providers;

use Illuminate\Support\Str;
use Laravel\Passport\Client;
use Laravel\Passport\Passport;
use Illuminate\Support\Facades\Schema;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        Schema::defaultStringLength(191);
        Passport::ignoreMigrations();
//        Passport::useClientModel(\App\Models\Passport\Client::class);

        if ($this->app->isLocal()) {
            $this->app->register(TelescopeServiceProvider::class);
        }
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */

    public function boot()
    {
        Client::creating(function (Client $client){
            $client->incrementing = false;
            $client->id = Str::uuid();
        });

        Client::retrieved(function (Client $client){
            $client->incrementing = false;
        });

    }
}

[sebastiaanluca]

Here's a Passport client model you can use that takes care of this for you: https://gist.github.com/sebastiaanluca/d4b5d2b5611fe9320b7ffa525c5ea0fa. Also be sure to have a correct migration, including $table->uuid('id')->primary();.

Edit: using passport:install is AFAIK not supported. The installation command does not create clients with UUIDs, but relies on the auto incremented ID field which you don't have when using UUIDs. You need to manually set those up.

[thamibn]

@sebastiaanluca thanks for your quick reply so how can i create them UUIDs except using the command ``passport:install ```

[thamibn]

@sebastiaanluca cause i have tried UUIDs for user table and it works if i use postman however if use the command db:seed it generate the error of id need default value, does that mean when using commands the boot function is not triggered?

[thamibn]

@sebastiaanluca i have used that model like Passport::useClientModel(\App\Models\Passport\Client::class); but still i am getting the error? on the AppServiceProvider@register

[sebastiaanluca]

I was mixing things up yesterday, sorry 😅 Field 'id' doesn't have a default value means that Passport wants to create a client, but there's no value for that ID field specified since the migration doesn't allow it to be nullable. Since your code seems correct (as per https://codeburst.io/laravel-passport-assigning-a-uuid-to-your-oauth-clients-211a9bbd5a6e and https://mlo.io/blog/2018/08/17/laravel-passport-uuid/ for instance), I assume it's either a migration thing or something else you've set up differently.

But I'd ask on the Laracasts or laravel.io forums as this issue isn't meant to support non-existing features. I'm sure they can help you better there.

[thamibn]

@sebastiaanluca thanks for your help it is now working i made a mistake on the migrations and change all 'id' fields to uuid, only client_id and user_id fields needs to be uuid since my user model also uses uuid.

test repo https://github.com/thamibn/testrepo.git

[grEvenX]

With the possibility to override the OAuthClient and allow $keyType and $incrementing to be set, is there still a reason to keep this issue open?

[driesvints]

We've implemented a PR to automatically configure clients with UUID's when you set them up using the passport:install command. This will be in tomorrow's release.

Given the gigantic impact with making UUID's the default we'll not be reconsidering that particularly approach. At least now there'll be a native way to do this.