Posted on Leave a comment

API Authentication In Laravel 5.2

[callaction url=”https://www.youtube.com/user/JPlaya01″ background_color=”#333333″ text_color=”#ffffff” button_text=”Go Now” button_background_color=”#e64429″]Subscribe To My Youtube Page[/callaction]

Hours Saved!

Token based API authentication is something you are inevitably going to encounter if you plan on working with web/mobile apps (unless you are coding under a rock). The benefits are great, in fact here are six of them; However it can be a nightmare if you need to create your own token authentication server. As of Laravel 5.2, there is a new auth guard called conveniently api this guard allows us to check an api_token parameter against an api_token field on our users table in our database.

API Configuration

Almost everything is configured right out of the box, open up config/auth.php and you will see this block of code

  /*
 |--------------------------------------------------------------------------
 | Authentication Guards
 |--------------------------------------------------------------------------
 |
 | Next, you may define every authentication guard for your application.
 | Of course, a great default configuration has been defined for you
 | here which uses session storage and the Eloquent user provider.
 |
 | All authentication drivers have a user provider. This defines how the
 | users are actually retrieved out of your database or other storage
 | mechanisms used by this application to persist your user's data.
 |
 | Supported: "session", "token"
 |
 */
 'guards' => [
 'web' => [
 'driver' => 'session',
 'provider' => 'users',
 ],
 'api' => [
 'driver' => 'token',
 'provider' => 'users',
 ],
 ],

By default Laravel 5.2 uses the web guard, which is the traditional session based model. This model is great for a traditional web application but not suitable for API architecture. The next guard is the api this guard is suitable for routes that need to be consumed by mobile apps and the like. The reason why you would want to do this is because when you are making request from your client-side app, each request is mutually exclusive of the requests before and after it, thus each one requires authentication. In the traditional session based flow, user data is saved on the server and that session data is used in every request, not only is this approach not scalable, it isn’t efficient or as secure as one might think. API token authentication is faster, scalable, and more secure. The biggest benefit of all is that you can now use this token in other applications to access your own API if you so choose. If you would like to see an example leave a comment of what kind of app you would like to see this implemented in and I will write it, record it, and blog it!

Leave a Reply