Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I have an application that doesn't use an out-of-thebox authentication process, and I am trying to improve review/update the process to adhere to Laravel best practices.
The authentication is handled via Shibboleth single sign on. The site is actually not accessible until a user passes SSO authentication. If a user tries to hit the site without a recent SSO authentication, they are redirected to an IdP sign-in page. I have no control over the SSO process, and I also did not set up the redirect process. The specs don't call for a login page. I think the server has a Shibboleth configuration that does the authentication redirect to the IdP, because it's definitely not happening within the application code.
Once a user has passed SSO authentication they are redirected to the site, and the redirect includes some data that gets evaluated by the application middleware. The middleware runs for every non-API/image HTTP request.
The logic flow is that when a user hits any page, an authentication check middleware runs to see if an an authentication object has been saved in the session. If so, it allows the request. If not, it checks to see if some user attributes are available, and then parses those attributes and determines if user should have access. If no user attributes are available, the user is redirected to an error page. If user attributes are available but they don't meet the criteria for entry (such as having specific affiliations), then user is redirected to an access denied page. If user does pass evaluation criteria, then a few processes happen, like a new record is created in our usage log, and the last_login timestamp of the user record is updated. If the user does not have a record in the users table, then one is created using the data received from SSO.
The current setup actually works fine, but I noticed that it isn't making use of the Auth facade. It doesn't appear users are actually being managed with Authenticatable or any of Laravel's built-in authentication facilities, which is presenting a problem for me building new pages and features that will require some permission checks.
I guess my question is, in a general sense, what is the best way to "hook up" this process to Laravel's native Authentication/Authorization handling, so that I can start building features like audit logs? How can I take an allowed user and pass those details to the Auth facade so that elsewhere in the application I can make calls like $user = Auth::user() and $id = Auth::id()?
You can work on certain areas at a time.
Implement laravel Auth, ensuring a user is logged in.
And implement authorization which determines what a logged in user with role can or cannot do, see, edit, etc.
Don't forget to protect any id's used in a query, make sure it's the authenticated user. Meaning if passed in a query string or url parameter, it can be changed in the address bar, you cannot rely on it.
@jlrdw Thanks for the outline.
It's unclear to me how I would implement Auth in this case. The Auth::login() method checks credentials against a database. Do I create a class that implements the Authenticatable interface and overwrite the login function (I don't see a login functions there)?
@AnonymousCodeMonkey the Auth::login() actually accepts a user model and not credentials. For example:
if (SomeThirdPartyService::login($username, $password)) {
$user = User::where('username', $username)->first();
Auth::login($user);
return redirect('/home');
}
@AnonymousCodeMonkey see:
Manually Authenticating Users
Here: https://laravel.com/docs/10.x/authentication#authenticating-users
The documentation explains all of this.
Or if using a starter kit, start a new app and you will have to migrate your code to it. I myself do not use the starter kits, I use the regular authentication.
@leyduana Thank you, this is very helpful.
Please or to participate in this conversation.