Authentication and Authorisation

Before we start looking at storing state, we will introduce authentication and authorisation.

Later this week we will discuss ways of keeping track of which users are accessing a website. However, to keep the systems secure we will also need some form of access control. Otherwise, we could have users claiming they are a different person, or accessing functionality that should be restricted.

In this article we will examine ways we can:

• Confirm users are who they say they are (authentication)
• Confirm users have the right privileges to perform a task (authorisation)

Authentication

Authentication is our first step in access control. It allows us to confirm that a user is who they say they are. This includes systems such as passwords, security tokens etc.

Obviously, this is an important part of security. Having a robust authentication method allows us to trust that a user is who they say they are. With a weak, or broken authentication process, an attacker could gain access to the system as a different user.

We covered Authentication when we talked about Cryptography.

But as a recap the most common ways of implementing Authentication are known as the the Three factors:

• Something you know: For example passwords, PINs or other "Secret phrases"
• Something you own: For example, things like phone based 2FA via a text message, Ubikeys, pass-cards etc.
• Something you are: Biometrics

Two Factor Authentication

You can see that each of these elements has a set of strengths and weaknesses. We can offset these somewhat using two factor authentication.

With 2-factor we can improve security by using multiple ways of authentication. Usually, this is in the form of Something you Know, and Something you Own.

For example, When you try to login to Google using your password (Factor 1) They will ask you to enter a pin number that gets sent to your phone (Factor 2)

The benefits of this are obvious. Even if someone gets your Password, they need the phone to complete the login. However again we have the downsides of needing to carry the device around with us to access data.

Authorisation

Determines what authenticated users can access. For example can a user only access their own "private" messages, or is sensitive data restricted to those that need it.

Note

This is even more important from a complicance point of view.

GDPR has rules not only for the types of data that we collect, and consent from users. But also covers who has access to the data. Having PII available to people within the organsiation who dont need to have access to it, could be considerd a breach.

When it comes to authorisation, the most common approach is to assign different "access levels" to users.

Example

Consider a basic forum system. This could have three different access levels, each giving different functionality.

• Unauthenticated users would only be able to View posts
• Authenticated users can also make new posts, and edit their own posts.
• Administrators are able to view and edit any post on the system.

These access levels can become quite complex to meet the needs of an application, and to keep information segregated. The number of layers, and the privileges assigned to them will be application specific. However, if designing such a system the "Rule of Least Privilege" should apply.

Summary

In this article we looked at the various methods of authentication, and authorisation. We also discussed two factor authentication, and how it can make our systems more secure.

When we are storing user information in our programs, we need to keep track whether if the use is Authenticated, and the Authorization levels they have.