Authentication user "hold" for additional auth check

[DarkGhostHunter]

One of the most problematic authentication procedures in Laravel is to "hold" the user being authenticated for another check in the next request.

For example, an User may have Two-Factor Authentication (2FA) enabled. The only way to implement this system is by, in order of simplicity:

• Authenticating the user, but having a global middleware forcing to use a 2FA code to continue using the site.
• Stopping the login by throwing an Exception on an event listener Validated.
• Extending the SessionGuard (or create a new one), and force the developer to use it.

I think the authentication system could have a "on-hold" user on the session once the credentials are validated. It would work much like attempt(), but it would allow a set of callbacks to run before login the user in.

public function attemptLogin(Request $request): bool
{
    $credentials = $this->credentials($request);
    $remember = $request->filled('remember_me');

    return $this->guard()->attemptWith($credentials, $remember, function (Authenticatable $user) use ($request) {
        return $user instance of TwoFactorAuthenticatable
            && $user->hasCorrectTwoFactorCode($request->input('totp_code'));
    });
}

The attemptWith() method retrieves and validates the user, but doesn't logs him unless the next callback returns true, allowing the developer to intercede before the login, and without having to create a new Guard.

// SessionGuard.php

public function attemptWith(array $credentials, $remember = true, $callbacks, $keepUser = false): bool
{
    $this->fireAttemptEvent($credentials, $remember);

    if ($this->hasValidCredentials($user, $credentials) && $this->shouldLogin($callbacks, $user)) {
        $this->login($user, $remember);

        return true;
    }

    $this->fireFailedEvent($user, $credentials);

    return false;
}

public function shouldLogin(array $callbacks, $user): bool
{
    foreach (Arr::wrap($callbacks) as $callback) {
        if (! $callback($user)) {
            return false
        }
    }

    return true;
}

As you can see, the attemptWith() is pretty much the same as attempt() in the SessionGuard, but has additional checks to allow further callbacks to execute over the User.

If this is considered a good idea, it may be good to know which implementation could be the best:

1. Introduced it as part of the attempt() signature of the Contract, or add it as attemptWith().
2. Keep it as part of the SessionGuard only.