Laravel custom authentication
2Hats . 5 minutes

Laravel – Custom authentication and what happens under the hood

In this article, we will take a detailed look at how the default authentication works inside Laravel core. But first, we will learn how to create a custom authentication.

Laravel ships in with a great default user authentication. It even creates the views and routes for you if you run

All is well as long as we are good with the default users table and its authentication. But what if we want another authentication method. For example, you want to user a separate table called admin for authenticating admin users while keeping the normal users table for front end authentication. Let’s start looking at the config file auth.php in the config folder.

The guards and passwords are defined below

The password settings are used for resetting passwords and we will ignore this for simplicity for now. We will get to the driver later in the discussion. Provider is defined below

As you can see it defines the eloquent model that is used. Below are the steps needed

 

Step 1

Add a new guard in auth.php

Step 2

Add provider in auth.php

Step 3

Let’s create the modal and migration for our table – admins

The -m at the end will create the migration for you. Just copy the migration for the users table for now and run your migration.

Step 4

A normal eloquent modal would extend IlluminateDatabaseEloquentModel but this won’t do for authentication modals. If you take a look at the User modal you will see that it extends IlluminateFoundationAuthUser. So change your modal so,

At the top of the page, you have this

and make the class extend it

Step 5

Create a new controller AdminAuthController.php

Add the guard protected property. If this is not defined, Laravel uses the default guard set in auth.php (web)

Don’t forget to add the necessary traits for logging in, registering etc. in the new controller (just like the default AuthController class )

 

That’s about it! Now you can use Auth::login in the AdminAuthController just like AuthController but it will use the admins table. But what if we want to change the username field to something like user_name (for some weird reason).

 

Changing the username field

Just add a $username propery to your AuthController or AdminAuthController. By default, Laravel uses email as the username field.

Let’s see how this works. Open up the trait AuthenticatesUsers and go to the  login function. If you trace through it, you will see this.

So whatever value you add to the property, will be used as the username. For eg. if you want to use user_name (suppose that you need it like that for some wierd reason), you can do like so.

 

What happens under the hood?

So how does all this work? In order to understand this, please work along with me and open the files and go through them yourself. Lets begin with the AuthController. Take a look at this trait used by it – AuthenticatesAndRegistersUsers. This trait just has 2 traits, nothing else – AuthenticatesUsers, RegistersUsers. Lets take a look at AuthenticatesUsers. You can see the function login defined in there. It does a bunch of stuff like validation, lets skip to the place where it attempts to log the user in.

Take a look at the getGuard function which is called in that

As you can see, it looks for a property called guard and returns its value if it exists. This is why we added the protected $guard property to the AdminAuthController earlier. If we do not define it, the getGuard function always returns null which would mean that the default guard (web) will be used.

So next, we need to figure out what this does

That is a facade. If you don’t know what is a facade, take a look at our article about Facades. Take a look at the service provider IlluminateAuthAuthServiceProvider::class. You can see that it returns a singleton for the AuthManager class

The AuthManager class is where most of the magic happens. You can see the guard function in there so we have finally found it!

This doesn’t seem to be doing much. It just populates the guards array property. But let’s have a better look this class. We know that the resolve function is called so lets look at that first,

If you remember our guard settings, the driver was set to session.

So lets see if there is a method called createSessionDriver. Of course there is! Lets see what it has got.

Open the SessionGuard class.If you remember, We had figured out that the authentication happens in this line in the AuthManager class

The attempt method is defined here. If you had defined the driver as token, the guard class would have been TokenGuard. You can also see functions like user, id etc. So this is where the call goes to when we do – Auth::id() or Auth::user(). Also take a look at the trait GuardHelpers used in the SessionGuard.

 

Now we have figured out what happens under the hood during a normal Laravel authentication. Its always good to get an idea about how things underneath. It gives us the confidence needed when designing complex systems. If you require any expert advice regarding Laravel development services, need to hire a Laravel developer, or seek guidance on choosing the right platform and other eCommerce services, feel free to contact us.

blog
Greetings! I'm Aneesh Sreedharan, CEO of 2Hats Logic Solutions. At 2Hats Logic Solutions, we are dedicated to providing technical expertise and resolving your concerns in the world of technology. Our blog page serves as a resource where we share insights and experiences, offering valuable perspectives on your queries.
Aneesh ceo
Aneesh Sreedharan
Founder & CEO, 2Hats Logic Solutions
Subscribe to our Newsletter
Aneesh ceo

    Stay In The Loop!

    Subscribe to our newsletter and learn about the latest digital trends.