Now that we know what our Authentication middleware does, the next part is knowing what is an Authentication Guard.

So, what’s an Authentication Guard?

An Authentication Guard is the responsible of:

Locating the credentials in the Request. Retrieving the User using the Credentials. Comparing and validating the credentials. Returning the User authenticated for further use.

To accomplish these tasks, the Guard concept is comprised of two moving parts: the Guard Driver and the User Provider. These two have a clear separation of concerns: one locates and validates the credentials, and the other “provides” or “locates” the User of these credentials, the latter which must comply with the Authenticatable contract (or interface, if you want).

If you see your auth.php config file, you will see a key called guards . In here, each guard name will have a driver and a provider . This allows you to swap them without affecting the other, or create other guards with other drivers and providers. Think of Guards a bag of a driver and driver with a label.

config/auth.php

For example, in our web guard, you could change the “user” provider for an hypothetical “external” provider that will pull out Users from Twitter, Firebase, Auth0, or whatever, and keep the same “session” driver to maintain the user logged in. This “external” provider would persist the user data in a Cache or Database to avoid calling the external API during every Request:

'guards' => [

// ... 'web' => [

'driver' => 'session',

'provider' => 'external'

],

Don’t worry if you didn’t understand the configuration file, we will revisit this in the last part.

The Guard Driver

All guards comply with the base Guard interface. This interface sets the basic foundation to do three things: check if there is an user authenticated, validate the credentials being passed and return the user currently authenticated.

Illuminate/Contracts/Auth/Guard

This is used by the TokenGuard that ships with Laravel. The Guard checks for a token in the Request headers, and pulls out the User matching that. If the token is not present or incorrect, the authentication will fail.

This interface is extended by another, the StatefulGuard . As its name implies, this adds methods to conveniently authenticate the User, persist it through the subsequent requests, and invalidate the authentication. This is mainly done with the login() , viaRemember() and logout() methods, respectively.

Illuminate/Contracts/Auth/StatefulGuard

This is implemented by the SessionGuard . As it name implies, it uses the Session handler of the application to persist and identify the authentication information. This allows to keep the user logged in for as long the session is valid and not expired, since it will check this to continuously to pull out the user.

All of these Guard methods usually calls the User Provider, which is in charge of retrieving the Authenticatable user whatever it may be, like an API or the moon.

The difference between Stateful and Non-Stateful

If you didn’t catch the difference, here is a heads up. The Stateful Guard has methods to keep the user logged in, and for this to be possible, the Stateful Guard provides methods like attempt() and login() in charge of checking if a particular User has the correct credentials, and persist the authentication in the next Requests, like using the Session and the Remember Token.

Subsequent Requests won’t ask for the user password, but instead, the Remember Token. Either way, the Stateful Guard will retrieve the User using the Remember Token, using the User Provider.

Meanwhile, the Non-Stateful Guard (or the “Simple Guard” if you want) will Authenticate the User as long his credentials are correct, something the User will have to set in each Request. This happens a lot when you use an external APIs, which requires to set an special token in the Request headers, for all Requests, to identify the User doing the request.

The User Provider

The UserProvider interface sets the ground to identify and retrieve the User who wants to be authenticated. Whatever you do to accomplish that is your own business, as long it returns an instance of something implementing the Authenticatable contract.

Illuminate/Contracts/Auth/UserProvider

This User Provider has to retrieve the User by its ID, which in the database is usually the Primary Column, and also by a Token, which allows the User to be “remembered” or authenticated through multiple requests without exposing other credentials. This last credential is usually the “remember_token” column in the default users table. Again, whatever you use to persist and retrieve the token is your own business.

It’s also responsible for retrieving a User by a combination of credentials, like its name, password and other information, and validate the correctness of these credentials, like for example, checking if the password matches.

For example, the EloquentUserProvider receives an array of credentials to build a query, which checks if a User for these credentials is found. Latter, the User is received again but with credentials to compare if these are the same.

The Authenticable

When everything is good, we will retrieve the User, which should be an instance of Authenticatable . This interface is basically a contract that forces the developer to have common methods available to manage the credentials like the password, the remember token, and its unique identifier for authentication.

While usually the unique identifier is the Primary Column in a Database, this is not bound to that. In an extreme example, you could set his identifier to a unique UUID of a remote API.

Illuminate/Contracts/Auth/Authenticatable

This is very important: the Authentication mechanism is tied to implementations, not hard-coded to classes. If in the future you want to change the location of your Authenticatable Users from Firebase or Auth0 to your local database, you will need to change the User Provider from firebase to eloquent and that’s all.

In other words, the Guard Driver doesn’t care where you pulled out your User (an API, remote database, etc), and the User Provider doesn’t care who or where the user Credentials are being pulled out (cookie, session, Request headers, who knows). This allows to keep your site functionality the same without having to resort to practically rewire the whole authentication process.

In the next part we glue everything together.