DEV Community: Abdessamad MOUHASSINE

From Scratch : User Authentication (Part 2)

Abdessamad MOUHASSINE — Fri, 09 Nov 2018 16:58:32 +0000

In my previous article, I've exposed user identification solutions, and how we can make it simple and clean. In this article, I'm just going to talk briefly about the next step after a successful authentication, which is called : User authorization.

To summarize, user authentication is the process to check and retrieve the user object based on its credentials, as shown below:

                      ++++++++++++++++++
                      +                +
    Credentials --->  + Authentication +  ---> User?
                      +                +
                      ++++++++++++++++++

But, what should happen after a user has been successfully identified ?

In most cases, we have to check the user's ability to access the resource and reject the incoming request, with a 403 Forbidden error, if not authorized.

I don't have yet a clear vision about the implementation, but it will follow the same philosophy as authentication, where the boolean result indicates whether or not the the user is granted:

               +++++++++++++++++
               +               +
    User --->  + Authorization +  ---> boolean
               +               +
               +++++++++++++++++

I'm open to any suggestion, idea or article, on how to make the implementation as clean as possible. So, don't hesitate to share it in comments.

Thanks.

From Scratch: User Authentication

Abdessamad MOUHASSINE — Sat, 13 Oct 2018 12:38:04 +0000

Definitions

User Authentication is loosely defined as identifying the user based on his credentials. In other words, it provides access control for systems, by checking to see if the user's credentials match those saved in a database, in a data authentication server, or anywhere else.

The credentials, in the other hand, could be anything: an identifier, password, pin numbers, certificate, fingerprint, retina, voice. I mean anything that differentiate a user from another.

You can get more information about the authentication, its types and factors on this wonderful article.

Solutions

Developers and frameworks provide different solutions and visions, simple and complex, to manage user identification.

Let see some examples:

Zend Framework 2

Zend framework provides a dedicated module zend-authentication, which includes adapters for different authentication methods, and an AuthenticationService class.

use Zend\Authentication\AuthenticationService;

// Instantiate the authentication service
$auth = new AuthenticationService();

// Instantiate a dummy authentication adapter
$authAdapter = new Adapter($email, $password);

// Attempt authentication, saving the result
$result = $auth->authenticate($authAdapter);

After a successful authentication attempt, subsequent requests can query the authentication service to determine if an identity is present, and, if so, retrieve it:

if ($auth->hasIdentity()) {
  // Identity exists; get it
  $identity = $auth->getIdentity();
}

Laravel 5

Laravel is a huge framework in fact, offering also different solutions and tools to handle authentication.

Laravel's authentication services could be accessed via the Auth facade.

use Illuminate\Support\Facades\Auth;

if (Auth::attempt($credentials)) {
  // Authentication passed
}
else {
  // Authentication failed
}

The attempt method accepts an array of key/value pairs as its first argument, and will return a boolean if the user is found in the database using the values in the array.

The authenticated user can be retrieved again via the Auth facade.

use Illuminate\Support\Facades\Auth;

// Get the currently authenticated user...
$user = Auth::user();

// Get the currently authenticated user's ID...
$id = Auth::id();

Symfony 4

The Symfony's solution is quite complicated. The security module provides multiple classes and interfaces to handle authentication.

use Symfony\Component\Security\Core\Authentication\AuthenticationProviderManager;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Exception\AuthenticationException;

// instances of Symfony\Component\Security\Core\Authentication\Provider\AuthenticationProviderInterface
$providers = array(...)

// Instantiate the authentication manager
$authenticationManager = new AuthenticationProviderManager($providers);

// create a token, containing the user's credentials
$unauthenticatedToken = new UsernamePasswordToken($username, $password, $providerKey);

// validate the given token, and return an authenticated token
try {
  $authenticatedToken = $authenticationManager->authenticate($unauthenticatedToken);
} catch (AuthenticationException $exception) {
  // authentication failed
}

After authentication, the User object of the current user can be accessed via the getUser() from inside a controller, this will look like:

public function index()
{
  $user = $this->getUser();
}

or via the Security class, available from version 3.4:

use Symfony\Component\Security\Core\Security;

public function indexAction(Security $security)
{
  $user = $security->getUser();
}

Django 2

Django uses, by default, sessions and middlewares to hook the authentication system into request objects.

from django.contrib.auth import authenticate

def my_view(request):
  user = authenticate(username='john', password='secret')

  if user is not None:
    # A backend authenticated the credentials
  else:
    # No backend authenticated the credentials

The user, authenticated or not, is always accessible within the request object:

if request.user.is_authenticated:
  # Do something for authenticated users.
  ...
else:
  # Do something for anonymous users.
  ...

Passport.js

Authenticating requests is as simple as calling passport.authenticate() and specifying which strategy to employ. authenticate()'s function signature is a standard Connect middleware, which makes it convenient to use as route middleware in Express applications.

app.post('/login', passport.authenticate('strategy-name'), function (req, res) {
  // If this function gets called, authentication was successful.
  // `req.user` contains the authenticated user.
  res.redirect('/users/' + req.user.username);
});

Unfortunately, passport can only be used in an express-like applications, since authenticate() returns a middleware function. It doesn't provide any API to use independently.

Conclusion

In my opinion, the Django solution is the best one, because, unlike the others, it separates the authentication from login.

the authenticate function checks the user credentials against each authentication backend, and returns a User object if the credentials are valid for a backend.
but the login function saves the user’s ID in the session, making it persistent for several requests.

Signing in users is application specific. But user identification is shared between apps and systems, only the backend differs.

From the above, and other examples not cited here, I ended up with a simple, stupid authentication manager, that dispatches the user credentials to a list of handlers.

interface AuthManager {
  /**
   * Check the credentials and return the user
   */
  attempt (credentials: object): Promise<User | undefined>

  /**
   * Register an authenticator
   */
  use (name: string, handler: Authenticator): this
}

The manager is an implementation of chain of responsibility design pattern, and internally uses authenticators with the following contract:

interface Authenticator {
  /**
   * Try to handle the credentials, or delegate to the next handler.
   */
  process (credentials: object, next: () => any): Promise<User | undefined>
}

I'm still working on this implementation to make it clean and framework-agnostic.
You may take a look at the develop branch.

What do you think guys ?

From Scratch: Web Sessions

Abdessamad MOUHASSINE — Sat, 25 Aug 2018 16:00:39 +0000

Hello folks,

As a first contribution, I want to share with you my thoughts about web sessions. Let's start by defining what are server-side sessions ? then I will show you an example of an abstract class that manages sessions in a simple and elegant way.

Web sessions is an industry standard feature, that allows server applications to maintain and store user-specific data, during multiple request/response interactions between the client application, mainly the browser, and the server.

State management is the main purpose of web sessions, they have no relationship with cookies, requests, responses, programming language or framework. They all share the same members and behavior and could be written in any language.

Properties

The basic, and required, session properties could be:

A state which is the main attribute in the session class. it can be a simple Map object that holds the key/value pairs.
A unique identifier or token to distinguish a session from another.
A lifetime, or time to live (aka TTL) property to calculate an expiry time after a moment of inactivity. it correspond to the number of seconds a session can live before expiration.
Finally, a storage, or whatever property name, to store a persistence adapter. It will be responsible of saving and retrieving the session's data from the storage (a text file in the file system, a database or the internal memory of the program executing the application).

Methods

In object oriented programming, both members and methods reside in the same class. To be autonomous, a session instance have to:

save its state for further use,
destroy the data if the session is expired,
retrieve the state from storage on initialization,
and regenerate a new identifier when it's necessary.

So, our session class can have the below structure:

abstract class Session {
  /**
   * A Map object to store key/value pairs
   */
  private state: Map

  /**
   * A string that uniquely identifies the session
   */
  private id: string

  /**
   * A number of seconds, milliseconds or even minutes to get the expiry time
   */
  private lifetime: number

  /**
   * Storage driver is responsible of the saving/retrieving the session state
   */
  private storage: StorageInterface


  /**
   * Start the session, loading the state from the storage
   */
  public async start (): boolean

  /**
   * End the session, saving the state in the storage
   */
  public async commit (): boolean

  /**
   * Regenerate a new session ID, maintaining the current state
   */
  public async regenerate (): boolean

  /**
   * Invalidate the session, removing or flagging the session as expired
   */
  public async invalidate (): boolean
}

Methods like get(), set() and remove() ... etc, are necessary to manipulate the session state, but we'll ignore them for simplicity.

I've used TypeScript notation for the code example, and wrote a full implementation on Github, if you would like see it in action.

Storage

The persistence driver, that encapsulates the storage, is also thin and optimized. It has one, and only one, responsibility: Persistence.

interface StorageInterface {
  /**
   * Retrieve an entry by its key
   */
  read (key: string): any

  /**
   * Remove an entry by its key
   */
  remove (key: string): any

  /**
   * Save an entry's data for the given time
   */
  write (key: string, data: any, ttl: number): any
}

Wrapping up

This is the general concept of web sessions and their reason to exist. They offer the functionality (state management) not the usability (creation, transfer, encoding, or persistence).

The Decorator design pattern can be used to add more features to sessions without the need to modify or rewrite it from scratch. Unfortunately, web framework developers, repeat themselves, and re-implement the same session logic, over and over, with a different API.

Links