SQLSTATE[42S22]: Column not found: 1054 Unknown column 'provider' in 'field list' (SQL: insert into `oauth_clients`

Stefan Bogdanescu

Founder & Senior Architect · 2026-06-29

Laravel Company

Fixing the Mystery: Resolving SQLSTATE[42S22]: Unknown Column in Laravel Passport Setup

As a senior developer working with the Laravel ecosystem, we often encounter frustrating database errors, especially when dealing with established packages like Laravel Passport. The error you are facing—SQLSTATE[42S22]: Column not found: 1054 Unknown column 'provider' in 'field list'—is a classic example of a schema mismatch between what the application expects and what the database actually contains.

This post will walk you through diagnosing this specific error during the installation of Laravel Passport, explain the purpose of the missing provider column, and provide the correct, robust solution.


Understanding the Migration Drift Problem

You are attempting to run standard setup commands (php artisan migrate:refresh --seed followed by php artisan passport:install). If these commands succeed in running the initial migrations but fail during the Passport setup, it signals that there is a discrepancy between the database structure defined in your migration files and the actual state of the table.

The error specifically points to an attempt to insert data into the oauth_clients table, where the SQL query tries to populate a column named provider, but this column does not exist in the table definition.

Why Did This Happen?

This situation usually arises from one of two scenarios:

  1. Outdated or Modified Migration: The migration file that defines the oauth_clients table was generated at a point when the structure was different, or it was manually edited incorrectly, omitting necessary fields like provider.
  2. Dependency Mismatch: A dependency (like Laravel Passport) expects a certain schema structure to be present before it can successfully execute its setup routines.

When you run migrate:refresh, Laravel attempts to re-run all migrations. If the migration file itself is flawed, or if the database state doesn't align with the migration sequence, this mismatch causes the runtime error during data insertion.

The Solution: Correcting the Schema

The solution lies in explicitly correcting your migration file to include the necessary column before running the setup process again. This ensures that your database schema perfectly matches what Laravel Passport expects.

Step 1: Locate and Edit the Migration File

You need to find the migration file responsible for creating the oauth_clients table (usually found in database/migrations). Open this file and locate the up() method where the Schema::create('oauth_clients', ...) block is defined.

In your provided example, the original structure was:

public function up()
{
    Schema::create('oauth_clients', function (Blueprint $table) {
        $table->bigIncrements('id');
        $table->unsignedBigInteger('user_id')->nullable()->index();
        $table->string('name');
        $table->string('secret', 100)->nullable();
        $table->text('redirect');
        $table->boolean('personal_access_client');
        $table->boolean('password_client');
        $table->boolean('revoked');
        $table->timestamps();
    });
}

Step 2: Add the Missing Column

You need to add the provider column. In the context of OAuth, this column is crucial as it links the client application to an identity provider (like Google, GitHub, or a custom service). Since this relationship is often optional during setup, making it nullable is a good practice for flexibility.

Modify your migration file to include the new field:

public function up()
{
    Schema::create('oauth_clients', function (Blueprint $table) {
        $table->bigIncrements('id');
        $table->unsignedBigInteger('user_id')->nullable()->index();
        $table->string('name');
        $table->string('secret', 100)->nullable();
        $table->string('provider')->nullable(); // <-- ADDED THIS LINE
        $table->text('redirect');
        $table->boolean('personal_access_client');
        $table->boolean('password_client');
        $table->boolean('revoked');
        $table->timestamps();
    });
}

Step 3: Re-run Migrations

After saving the changes to your migration file, execute the migration command again. This time, it will correctly create the table structure with all necessary columns:

php artisan migrate:fresh --seed
# or if you prefer refreshing existing data:
php artisan migrate:refresh

Now, when you run php artisan passport:install, the insertion process will succeed because the provider column is defined in the database schema.

The Purpose of the provider Column

The provider column in the oauth_clients table serves a fundamental role within any OAuth 2.0 implementation, which Laravel Passport heavily relies upon.

In simple terms, the provider field identifies which external service or identity system an application is authorized to use for authentication. For example:

  • If you are integrating with Google Sign-In, the provider column would likely store 'google'.
  • If you were setting up a custom internal authentication flow, it might store 'web' or a specific identifier.

This field is essential because it allows the system to distinguish between different types of OAuth clients accessing your API, enabling granular authorization checks within your application logic.

Conclusion

Schema mismatches are inevitable in complex development projects, especially when dealing with automated migrations and third-party packages. The key takeaway here is to treat your migration files as the single source of truth for your database structure. Always inspect your migrations before relying on package setup routines. By explicitly adding missing columns like provider in your migrations, you ensure database integrity, eliminate runtime errors, and maintain a robust foundation for your application, aligning perfectly with best practices promoted by the Laravel community at laravelcompany.com.