Enhancement Proposal: Add Morph Relationship Support to Sessions for Multiple Authenticatable Models

[eslam-reda-div]

Hello everyone,

I’d like to propose an idea that could improve how sessions are managed when working with multiple authenticatable models (e.g., User, Admin, etc.).

Problem

Currently, the default sessions table structure does not provide a clear or direct way to distinguish between different types of authenticated models. For example, if an application uses both users and admins guards/models, there is no built-in way to:

• Query sessions for a specific model type (e.g., only admin sessions)
• Cleanly separate or manage sessions across multiple authenticatable entities
• Apply model-specific session policies or analytics

Proposed Solution

Introduce a polymorphic (morph) relationship in the sessions table, such as:

• authenticatable_type
• authenticatable_id

This would allow each session to be directly associated with any authenticatable model using Laravel's morph relations.

Benefits

• Easily query sessions by model type (e.g., Admin::sessions())
• Better separation of concerns in multi-auth systems
• More flexibility for auditing, analytics, and session management
• Cleaner integration with existing Eloquent relationships

Example Use Case

Admin::find(1)->sessions;
User::find(5)->sessions;

Considerations

• Backward compatibility with existing applications
• Optional feature (only enabled when needed)
• Possible integration with guards

I’d love to hear your thoughts on this. Do you think this could be a valuable addition to the framework, or is there an existing approach that already solves this cleanly?

Thanks!

[benjdiasaad]

Hi @eslam-reda-div,

This is an interesting proposal, and I agree it highlights a real limitation when working with multi-auth setups.

That said, I think this might be more of an application-level concern rather than something that needs to be handled directly by the framework.

Laravel’s session table is intentionally kept simple and guard-agnostic. The framework doesn’t tie sessions to a specific authenticatable model because authentication is resolved through guards at runtime, not persisted as part of the session schema itself.

In practice, most multi-auth setups handle this in one of these ways:

• storing the guard or user type in the session payload (or a custom column)
• using separate session stores per guard when stronger isolation is required
• relying on guards and middleware to scope behavior rather than the database structure

Introducing a polymorphic relationship (authenticatable_type / authenticatable_id) would definitely make querying more convenient, but it also couples the session layer more tightly to Eloquent and specific models, which Laravel usually tries to avoid at the core level.

I think your idea makes a lot of sense for applications that need advanced auditing or analytics. In those cases, extending the sessions table (or creating a custom session driver) is probably the most flexible approach without adding complexity to the framework itself.

So overall:

• valid use case
• but likely better handled at the application level or via customization rather than in the core

Curious if others have taken a similar approach with custom session drivers or additional metadata on sessions.