Owners & key types

Every token row carries owner_type (the owner’s morph class) and owner_id, with a composite index. Owner-scoped queries — listing, revoking, family inheritance, session lookup — always match both, so user #7 and client #7 never see each other’s sessions:

use RoundlyConsulting\RefreshTokens\Facades\RefreshTokens;

$user = User::find(7);
$client = Client::find(7);

RefreshTokens::sessions($user)->all();    // only User #7's sessions
RefreshTokens::sessions($client)->all();  // only Client #7's sessions — the ids never collide

owner_type respects your morph map, so you can store short aliases instead of class names:

use Illuminate\Database\Eloquent\Relations\Relation;

// owner_type stores the morph class, so your morph map is respected:
Relation::morphMap([
    'user' => \App\Models\User::class,
    'client' => \App\Models\Client::class,
]);

Key type

The owner_id column matches your owner models’ primary key. Set key_type before the first migration:

• bigint (default) — the usual auto-incrementing integer column.
• uuid — for UUID-keyed owner models.
• ulid — for ULID-keyed owner models.

All owner models must share that key type — a bigint User and a uuid Client cannot share one table. owner_id is the model key (getKey()), resolved like any Eloquent morph, not the auth identifier. Any other key_type value throws InvalidConfigurationException naming the key and the value — including id, the package’s former spelling; use bigint.

Guard-scoped redemption

When one app runs several sign-ins, each refresh endpoint can accept only its own owner type. A token of another type is treated as unknown — it is not consumed and never counts as reuse. See Redeeming & rotating for the details.