Authentication and authorisation are critical security elements on all websites and applications. To make sure our developers are up to speed we put this information together as a primer on authentication within Laravel. The members of our team not already familiar with some of the terminology have found it useful so we’ve decided to share it with you.
First let’s start with some definitions:
Authentication — Confirming your identity (typically with user/password combination for example).
Authorisation — Deciding if you have permission to access functions or resources.
Client — The application making requests to the API on behalf of its owner. This could be a browser, a mobile app or a desktop app for example.
Resource Owner — The owner of the data that the client wishes to access, typically a user.
Resource Server — The server that holds and protects resources that require permission via an access token to use. It may also hold other public, unprotected data that does not require an access token.
Authorisation Server — The server that issues access tokens after successfully authenticating the resource owner.
Scope — Effectively a permission to carry out certain actions or access certain data.
Grant — The method by which an access token is provided.
Access Token — An object that contains the security credentials required to access elements of a resource server.
Authorisation Code — The temporary code that the client will send to an authorisation server to exchange for an access token.
JWT — JSON Web Token (See JWT section below).
Passport — Laravel’s official package that implements Oauth2 and JWT (See Passport section below).
Oauth2 — An open standard for token-based authentication and authorisation for API and web logins (See Oauth2 section below).
Auth0 — An alternative to Laravel Passport in that it provides authentication and authorisation as a service, utilising Oauth2 or other standards and protocols such as OpenId. Can be used for SSO (single sign-on) applications.
So let’s now look at how Laravel deals with authentication.
Overview of Laravel’s authentication configuration:
Laravel’s authentication system uses guards and providers. Guards define how users are authenticated, providers define how users are retrieved from storage.
You can see the defaults in
'guards' => [ 'web' => [ 'driver' => 'session', 'provider' => 'users', ], ... ],
Check the official documentation for customising these options.
The session driver shown above is used by Laravel’s built-in authentication system. This can be scaffolded with the
php artisan make:auth and
php artisan migrate commands. This builds you the default authentication system views, database structure, models, routes and controllers.
This default setup uses session storage and cookies to maintain the login state. And uses eloquent and the User model as default provider configuration.
For standard web applications that do not need to expose an external API, this type of authentication is generally all that is required. However there are other options available if needed.
JSON Web Token is an open standard that defines a way of securely transferring data as a JSON object. JSON Web Tokens contain three parts: the header, the payload and the signature.
The header defines the type of token (in this case JWT) and the signing algorithm used.
The payload contains the “Claims”, these are typically information about the user (such as Name or User Permissions) and any other relevant information, and include details of when the token will expire.
The signature is generated by combining the header and payload and encoding them with the specified algorithm and secret key.
In a system with JWT configured, once a user signs in, a token is generated and returned to the user. The information is encoded using a key that is managed by the server (In Laravel you would typically store this in your dotenv file). Whenever a user then wishes to access the system, the user agent (a browser or app) will send the JWT to the server where it is decoded using the key, and if the details are correct, the user can the access the relevant resources on the server.
This is a useful system for securing your API endpoints and authenticating your API users.
A well documented package is available for Laravel called JWT Auth that helps to quickly implement JWT into a project.
However for systems where there is regular and frequent communication between clients and a server, as the JWT is sent with every request, there are other options that may be more efficient that utilise server-side sessions.
A quick few words about OAuth2. OAuth2 is an authorisation framework that allows applications to obtain limited access to other web service accounts, such as Google or Facebook. This can be used to sign in and provide user information to a third party application.
Laravel Passport is the native OAuth 2 server for Laravel applications. Once installed following the documentation, the Laravel Passport package comes with database migrations, routes and middleware to ultimately create an authorisation server that will return access tokens to allow access to server resources.
The way in which an access token is obtained from the authorisation server is called a Grant.
We won’t go into full detail on each but as an overview the main types of Grant are:
Authorisation Code grant
Used by most popular APIs, this is commonly used when one application requires access to resources held in another application. An example of the flow would be:
- The user attempts to log in to an application via a client
- The client redirects the user to an authentication server where they are prompted for their login details
- Upon entering correct credentials the authentication server directs the user back to the original application with an authorisation code
- In the background this code is used to request an access token from the authentication server
- The access token is received and used to allow access to data on a resource server
- The user can access the protected resources
Client Credentials Grant
Used for machine-to-machine communication, where there is no user interaction. Instead the client sends a client id and client secret to identify itself and is granted an access token.
Commonly used for API access for mobile applications owned and developed by the same party as the web application. The server trusts the client so upon authenticating login details an access token is sent directly to the client.
Refresh token grant
As access tokens expire, they can be sent with a refresh token. This can be sent to the auth server to obtain a new access token without requiring user input.
While this is not meant to be an exhaustive guide, we hope it covers off some of the main elements of authentication in Laravel, and will provide you with the terminology and background to do your own research into which system will work best for you.
We’re happy to advise on what might work best for your project and will always consider carefully the most appropriate authentication system when building your projects.