One of the questions I am asked all the time about the Stormpath Laravel package is, “Why do I need to use a package for authentication in Laravel when it is built in?” I will be the first to admit that the Laravel authentication is well built and a great addition to the framework. It saves a lot of time during your development. However, it still requires you to understand the security aspects around storing user data.

There are also many different areas inside of the Laravel framework that requires you to do a lot of custom configuration of your users table. Things like gates to see if the user is allowed to perform actions, and the ability to have one database for authentication to be able to share across multiple applications. At Stormpath, we also have secure and current hashing methods for our passwords to keep your users safe. (You can check out the Stormpath Laravel integration on Github right here!)

Password Hashing

Throughout the years, there have been many different ways people would hash passwords. Most of the old ways, when judged by today’s standards, are considered insecure and should no longer be used. There have been improvements in hashing algorithms in php in the last few years, however, and one of the main hashing algorithms used today is bcrypt. Laravel by default will use bcrypt hashing to encrypt any password that is run through the Hash facade.

How bcrypt Password Hashing Works

bcrypt was introduced in 1999 by Niels Provos and David Mazières, based on the blowfish cipher. Passwords that are hashed with bcrypt are a little unique looking but this has a good reason behind it. Let’s take a look at the password Sup3rP4ss! and run it through the Laravel Hash::make command.

Lets break this password up into its parts.

$2y$10$q4OXsiCxv4efAi/zzWVbIOCUE.JnXofL779/e3Vs9H4ocnGcdekiK

The $2y$ states that this is a bcrypt hash in modular crypt format. Modular crypt format, or MCF, is a standard for encoding password hash strings. Other options the password may start with are $2a$ or $2b$.

The next part of the hash is the cost. This defines how many iterations over the hashing you want. This iteration count will be 2^cost value. Typically, this cost is 10 and is fine, but if your computer hardware can handle more, you can increase this value. Third in the string is the actual salt that is used for hashing. As of php 7.0.0, the option to set your own salt was deprecated. Behind the scenes, php will use the password_hash() method to generate a salt for you while creating the hashed password. The last part of the string is the resulting hash. The user’s password is never stored. Once you put all that together, you will receive a 60-character string that you can safely store in your database.

How Stormpath Password Hashing Differs From Laravel

Laravel Hashing uses the secure password_hash() method that is built into php with the algorithm of PASSWORD_BCRYPT set to generate the bcrypt passwords which are stored inside of the database for you. This gets you about 90% of the way to a fully secure setup for your users. That extra 10% is what Stormpath gives you to protect your users and their data.

Stormpath uses cryptographic best practices for user data storage and eliminates the need for manual data hardening. The ideas are the same to start with when we generate a password for our users, but then we add in a few more steps to further protect the data. We add additional computational complexity to increase the time it would take to brute-force a password. We also add encryption to your password hashes. Using a private key that is rotated and never reused, as well as stored in a different location, means the final encrypted password would take thousands of years of computing power to crack.

The final Stormpath differentiator is that we are always using the latest password hashing and cryptographic best-practices. Without any updates to your code, you will always be secured with the latest in password hashing, relieving you of the pain of keeping up with the updates and maintenance that goes along with this.

Groups And Roles

Access management of routes and resources is typically a big part of applications that are built. Stormpath and Laravel both support this in their own way. Laravel’s Gate facade provides a simple way for you to control access to these resources, out of the box.

Setting Up Gate In Laravel

The Gate facade is a great feature that was added to Laravel in version 5.1, however, it requires some database configuration and updates to your user model to set it up fully. For this example, let’s make a gate to see if the user is an administrator. The first step is to modify the user database to add a column for canCreateUsers which will be a boolean. Create a file in your database migrations:

From here, you need to create some way to modify the user to make the canEditPost column to true. After you get this all set up and working, you then need to create a new function on your User model canCreateUsers or whatever you want to call it.

This step is not 100% necessary because you can just use $user->canCreateUsers in the function, but I always suggest adding a method here in case you want to do any other modifications to this check.

Once you are done with the two file modifications, we can finally start creating the gate. A note about gate is that it works closely with the logged in user. The gate needs to be created and registered in AuthServiceProvider:

Now that all this has been created in your database and set up in your application, you can protect things in your application. Wouldn’t it be nice to not have to modify your database every time you need to create a new role for users? How about not creating the workflow to add users to a role? This is all possible out of the box with Stormpath.

Creating A Gate For Stormpath User

With the gate interface being so tied into the Laravel authentication, we, unfortunately, are not able to use some of the gate features. However, we can use a lot of the same ideas behind it and roll our own. The first thing to do is define the roles you want. We will continue with the same idea for allowing a user to create other users. Let’s go to your Stormpath dashboard and create a new group users.create

Create Stormpath Group
Creating a Group in Stormpath Dashboard

Next, assign this group to the users you want to have access to this ability.

Add Group To User
Adding a Group to a User

That’s all the setup there is on the “database” side. The next thing is to create your method to see if a user can create a user. The way to approach this is to create some middleware.

Then, in your routes file for the get and post of creating a new user, you would add this middleware requirement.

Shared Users Across Applications

This is one of the places where I believe Stormpath goes a step further than the Laravel built-in authentication. Inside of Laravel, it is difficult to set up your application to speak to a user database and then for the core application to speak to a different database. I’m not saying here that it’s not possible, just difficult, and it requires you to do some checks and database switching on the fly. With a Stormpath setup, this is a very simple process once you have the Stormpath-Laravel package installed.

Setting Up Central User Database In Laravel Using Stormpath

During the initial setup of your first application, you would have edited the .env file to define your API Keys and Application HREF. There’s not much more than that for your second application. Add the same values to your second, third, fourth, etc… Laravel applications to point them to the same Stormpath application and you are ready to move on. Doing this, allows you to have as many Laravel applications as you want using the set of users that are in your Stormpath application.

One use case for this that I have personal experience with is a multi-tenant application in Laravel. When provisioning a new tenant on this application, they would get their own database. The reason the application was set up like that was so I could upgrade one tenant with a new “edge” version of the application, without messing up any of my other tenants. Doing this inside of Laravel alone, you would have to do some sort of switch on the database to see which tenant was logging in, change the database name to that tenant, and then do the DB queries.

What’s Coming Next For Stormpath?

There are a couple of plans for the Stormpath Laravel package. The first of these is to integrate more closely with the actual Gate facade to make the process much easier. Once this is done, you’ll be able to define the gates like any other in the core framework of Laravel instead of having to use the middleware. The second is multi-tenancy. This is a request we hear a lot from our users, and we are actively working on a solution and update to the integration to support this.

I hope you found this information useful in both determining how Stormpath differs from the built-in Laravel authentication and understanding the extra steps we take to help you secure your data and manage your users with ease. I always love to hear feedback on what you like and dislike about Stormpath php and our integrations. You can contact me at [email protected], or on twitter @goStormpath, or leave a comment below!

// Brian
?>