Lumen is Laravel's little brother: a fast, lightweight micro-framework for writing RESTful APIs. With just a little bit of code, you can use Lumen to build a secure and extremely fast RESTful API.
In this video tutorial from my course, Create a REST API With Lumen, you'll learn how to use Lumen's built-in authentication middleware to secure a REST API with Lumen.
The video refers to code from a sample music store API that we created in earlier lessons of the course. You can view the full source code from the course on GitHub.
How to Secure a REST API With Lumen
Authentication in Lumen
Security is a very important part not just of a web API but of an application. And unfortunately, implementing authentication can be a difficult thing. But thankfully, authentication is built into Lumen, so that all we need to do is enable authentication and then write a few lines of code to authenticate a user and then a few more lines of code to protect the things that we want to protect.
In our example, we want to protect three methods on our guitar controller. They are the create, update, and delete methods. These are things that only an authenticated user should have access to.
So let's start by going to the bootstrap folder and opening up app.php.
There are two statements that we need to uncomment. The first is the call to routeMiddleware
, which is setting up the authentication middleware. We also want to register the auth service provider. So the second statement is $app->register(App\Providers\AuthServiceProvider::class);
. Just by uncommenting those two statements, we can now use authentication in our application.
Now we want to make note of our authentication middleware. So let's go to App\Http\Middleware\Authenticate.php
, and inside of this class there is a method called handle
, and this method will execute before our protected methods.
So any time that we make a request for our create, update or delete methods, the authentication middleware is going to be used, and this handle
method is going to be called.
If the user is not authenticated, then it will return a 401. Otherwise, it will pass the request on to the next thing that will process that request.
So that is one thing that we needed to look at. The other is inside of the Providers folder, and it's AuthServiceProvider.php.
Now at the bottom of this file is a method called boot
, and inside of boot is a call to this viaRequest
method. And this is the method that is responsible for actually authenticating the user. So this is going to be dependent upon our implementation. And in this lesson, our implementation is going to be very simple.
What we are going to do is check for a header called Api-Token. And if it's a certain value then we are going to say that the user is authenticated. In order to say that a user is authenticated, we have to return a user instance. If we return null, then that means that the user is not authenticated.
So let's go ahead and write that code. I'm going to comment out this existing code. And the first thing we're going to do is retrieve the Api-Token header. So we're going to use our request, we're going to call the header method, and we want Api-Token.
$header = $request->header('Api-Token');
Now, let me first of all say that this is not secure. We would definitely want to store our users in a database. They should each have their own unique tokens and really we should be working with private and public keys. But I'm going to leave all of the implementation details up to you. What we want to see is how the authentication middleware plugs into our application so we could get that working, and then you can implement whatever it is that you want to implement.
So we are going to retrieve the header called Api-Token. And let's first of all check to see if we have something there.
Now, the only other thing that we need to do is say where we want to use our authentication middleware. We can do that in a variety of places.
The first is whenever we define our routes. For example, we want to protect our post request. So instead of writing our route like we did, we could do this. It's essentially the same thing, but the second argument that we passed to the post method is going to have two keys and values.
So without going any further, we could hop on over to Fiddler and we can make a post request and we could see if that would be protected.
Now one of the great things about Fiddler is that it keeps track of all of the requests that we have made. So we just need to find where we made a POST request. And if we try to execute this, we'll get a 401. But if we include that Api-Token header, and if we set that to "birds fly south", then whenever we make this request we'll get a 200, and we already know that that data is now in the database.
So that's the first option. But the second option is to specify our middleware inside of our controller's constructor. So let's comment out the code we just wrote and instead use our old route.
Let's go to our guitar controller and add the following code:
So if we go back to Fiddler and if we issue that same request—let's just change the value to a strat and the make to Fender—then we are going to see that it still works. So when we execute that request, we get a 200. If we take out the Api-Token, then we get a 401.
Now let's also issue some of the other requests. So let's do a GET request so that we can retrieve those guitars and get their IDs. Let's get rid of the Api-Token just so that we can see that this works without any type of authentication. And we get ID of 1 and ID of 2.
So if we go back to the composer, let's make a PUT request for the guitar with ID of 2.
For the data that we are going to send, the make is going to be Fender, but let's change the model from a strat to a telecaster. Now without the Api-Token, this should not work. So whenever we execute, we get a 401. But let's add the Api-Token and then the value, birds fly south, and that request is going to return 200.
So just for the sake of completeness, let's do a DELETE request. Let's delete the guitar with an ID of 1. We should get 200, and a let's re-issue the request to retrieve all of our guitars. And we should just have one, and it should have an ID of 2. The make is Fender, and the model is telecaster.
So adding authentication to a Lumen application is very, very simple. Other than adding the middleware, the bulk of the code that you have to write is inside of the AuthServiceProvider
class. You have to write the code responsible for authenticating the user, but once that's done, you have a secure API.
Watch the Full Course
In the full course, Create a REST API With Lumen, I'll show you how to get started building REST APIs with the Lumen framework. You'll start by setting up a Lumen development environment and go on to build a complete API for a music store, including routing, MySQL database connectivity, and security.
Comments