The NetTuts.com site has posted a tutorial for those looking to simplify the authentication of users in their PHP applications. In this new article they show how to use the Auth0 service to offload some of the burden of user management and authentication flow.

In this article, we're going to explore the Auth0 service, which provides authentication and authorization as a service. Auth0 allows you to set up basic authentication and authorization features for your apps in the blink of an eye.

The article starts with a brief overview of what the Auth0 service offers and what particular ones will be involved in the tutorial. To help make it simpler to get up and running, they've created a base application. They show how to get this application installed and configured to use the secrets values from your Auth0 account. It then walks through the various scripts included in the sample application including a login, logout and code to perform the actual authentication flow process (including validating the access token).

On the TutsPlus.com site there's a new tutorial posted for the Laravel users out there covering a few pieces of the authorization features of the framework. The tutorial covers "gates" and "policies", introducing some of their basic concepts and providing example code to implement your own.

Today, we're going to discuss the authorization system of the Laravel web framework. The Laravel framework implements authorization in the form of gates and policies. After an introduction to gates and policies, I'll demonstrate the concepts by implementing a custom example.

I assume that you're already aware of the built-in Laravel authentication system as that's something essential in order to understand the concept of authorization. Obviously, the authorization system works in conjunction with the authentication system in order to identify the legitimate user session.

The article starts by introducing some of the basic approaches the framework takes to authorization handling and where gates and polices fit in. It then gets into the details of each including example code showing how to define them based on the interfaces provided. The tutorial then shows how to put them to use in a simple application, applying them at both the controller and view level.

On the Laravel News site there's a new post highlighting a package that can help you enforce roles and permissions in your application, enhancing the existing gates functionality.

Bouncer is an authorization package by Joseph Silber which allows role and ability checks at Laravel’s authorization gate. The package is described as follows: "Bouncer provides a mechanism to handle roles and abilities in Laravel’s ACL. With an expressive and fluent syntax, it stays out of your way as much as possible: use it when you want, ignore it when you don’t."

Bouncer makes it trivial to quickly create roles and abilities with a fluent API that creates them automatically.

The post includes some examples of the library in use, creating roles and abilities with its fluent API and the use of a trait to integrate it into other classes. They also include a bit about how the automatic role creation works and using the functionality in middleware. It also talks about how Bouncer intercepts "can" checks for its own evaluations and how to get all of the abilities for the current user.

Previously the Zend Framework blog posted a tutorial showed you how to authenticate a user with middleware in a Zend Expressive application. In this latest post in the series they move on to the next step: authorization.

In a previous post, we demonstrated how to authenticate a middleware application in PHP. In this post we will continue the discussion, showing how to manage authorizations.

We will start from an authenticated user and demonstrate how to allow or disable actions for specific users. We will collect users by groups and we will use a Role-Based Access Control (RBAC) system to manage the authorizations.

To implement RBAC, we will consume zendframework/zend-permissions-rbac.

They start by pulling in the Zend Expressive tooling support and creating the Permission module. The tutorial then gets into the basics of using a role-based access control system and the roles they're going to define: admin, editor and contributor (as well as what each can do). The roles are then defined in a configuration file and briefly explained. Next is the creation of the middleware to authorize the user and its action in the application, performing a check against the roles of the user on the requirements of the action. There's also an example of setting up role inheritance and how to configure the resulting route to fire off the authorization handling.

On the Laravel News site there's a new post introducing you to "authorization gates" in Laravel, a feature that allows you to ensure a user has the permissions to perform the action being requested.

Laravel Gate has an elegant mechanism to ensure users are authorized to perform actions on resources. Before version 5.1, developers used ACL packages such as Entrust or Sentinel along with middlewares for authorization.

The problem with this approach is the permissions you attach to users are just flags; they don’t encode the complex logic of the permission for some use cases. We have to write the actual access logic within controllers.

They mention some advantages to using Gate over other external packages (like Sentinel or Entrust) by being "opinionated" about its use and the decoupling of access logic from business logic. They then share an example in a basic Laravel application, protecting "posts" based on the user's current roles. Models, migrations the auth generation are all included. They then show how to define policies in the AuthServiceProvider for CRUD operations on the posts and how to enforce their checks in the Post controller execution flow.

On the Stovepipe Systems blog author Iltar van der Berg has retuned with a continuation of his series on Symfony security basics with this new post covering voters and roles.

In my previous blog post I've explained the basics of authentication, authorization and how this is dealt with in Symfony. Due to the size of the post, I've left out several important topics such as roles and voters; Both an equally important part of authentication and authorization. A common misconception is that roles should be used to check permissions. In fact, they should definitely not be used to check permissions!

He goes on to explain where "roles" come into the process of authentication (not authorization) and how they describe something about the user of the system. With that defined he moves on to the "voters": functionality that "vote" on attributes related to the user/request/resource/etc. and return a pass or fail decision based on their logic. He explains why voters are probably more what most developers are looking for and some reasons to use them over roles. He then ends the post showing how to create your own custom voter and configure it into your application.

In a new post to his site Alex Bilbie looks at a good approach to simplifying the OAuth 2 authorization flow for a device and some of the simple PHP that can power it.

When signing into apps and services on devices such as a Playstation or an Apple TV it can be immensely frustrating experience. Generally you will ordeal something similar to one of the following scenarios: The utterly terrible experience whereby you don’t have anything other than an onscreen keyboard [or] A slightly less terrible experience whereby you can pair a bluetooth keyboard to enter your username and that crazy long password.

[...] There are some apps however - such as Youtube for Apple TV - that have a much better end user experience.

He talks more about this better experience involving a simple code presented to the user, a special URL to link the device and the typical OAuth-ish authorization page to link the request to your account. He then explains how it would work with a PHP backend: making the request to the auth server, returning a message with the codes and URL to pass along and the "device code" it responds with. He also includes a few examples of error responses for polling too quickly, pending authorization and a denied request. This is all based on the (currently in draft) OAuth 2.0 Device Flow Grant currently in the works.

Lorna Mitchell has a post to her site with some helpful instructions for the CakePHP3 users out there around access control. The framework comes with no built-in functionality for authentication so she shows how to set up your own.

The newest version of CakePHP doesn't ship with built in ACL, which means you need to write your own. Personally I think this is a smart move, having looked at the one-size-fits-all solutions for previous versions of the framework and knowing that every system has different requirements, this version has good hooks and documentation on how to add something that works for your application. I thought I'd share what worked for mine.

She starts with some of the initial setup: creating the relationship between the users and her custom roles table and "baking" the controllers and templates. She then goes through the use of the authorize method and how it can handle the user/request combination to determine access. She includes the code for her auth class, showing both the authorize method and a simplified userHasRole method. She walks you through the code and one downfall the setup has: not being able to validate access in views and templates.

In this post to his site Mohamed Said shows you how to build an API that allows for easier integration with your content/functionality by 3rd party applications. This example uses the Laravel framework but the ideas could be applied in any framework.

APIs are cool, & laravel can handle all the coolness you may desire. Here we talk about building an API for third party applications and allowing them to communicate with your application on behalf of users.

He starts where any good project should: planning for what features need to be included and the flow of the request/response process. He then walks you through the whole process for setting up the API:

• Updating the routes for the API request endpoints
• Creating the new Auth and Home controllers
• Setting up the migration for the "applications" table
• Using the firebase/php-jwt library for authentication/authorization handling
• Registering a token and validating it on the incoming request

He wraps up the post talking about user authentication via a simplified OAuth-ish process flow, making requests using the resulting token and logging the user out (expiring the token).

The SitePoint PHP blog has posted a tutorial showing you how to "take the pain out of user authorization" with the help of Sentinel, a package from Cartalyst that already includes functionality for both user authorization and authentication.

Most non-basic multi-user applications need some roles and permission levels. If you ever used WordPress, you must have noticed that they have a super admin, admin, editor, author, etc. Simplifying the development and integration of a permission system is what Cartalyst’s Sentinel package is trying to accomplish. The package provides an API for dealing with users, groups, permissions, etc. In this article, we’ll use it to create a small demo app.

They walk through the creation of a simple Slim framework application, installing it, Sentinel and other suggested packages via Composer. They then help you execute the migrations to create the necessary tables and set up a basic front controller file. From there they configure Twig templating, the Illuminate database connection and finally adding a Sentinel instance to the application's DI container. They include code to help you create roles for "user" and "admin". From there the tutorial shows how to create a login & registration form, send a registration email, create permissions and activating users. Finally they build a simple administration page that allows you to hide functionality from normal users.