Goals of an Auth System

Recently, I’ve been working on building an authentication microservice that I can utilize in future projects. This article aims to explain the goals of an auth system and go over some key terms that help clarify these goals.

What is the goal of an auth system?

The primary goal of any auth system is to have processes in place to accomplish two things: the system has the means to identify that the individual is who they say they are, and a way to determine that the individual has the appropriate permissions to access the intended resources.

What is Authentication?

The first part of the goal describes authentication (also referred to as AuthN). Authentication requires that the system being accessed needs a way to identify the individual via some kind of evidence. In most cases, this can mean identifying the user via something they provide.

The first step to authentication is identification. The common way we see identification is via login forms, where we provide a username to identify ourselves and a password, which is the shared secret between the individual and the service/app.  The login page on a web app demonstrates the basic foundation of any authentication system comes in two parts: (1) an individual must be able to identify themselves, and (2) that individual must be able to prove their identity.

These 2 mechanisms can be extended to far more than just web apps. In fact, the world around us is filled with authentication systems that we may interact with on a daily basis. When we swipe a badge to get into work, we authenticate ourselves into the building by identifying ourselves and providing proof of ourselves with a badge. When we log in to buy an item off Amazon, we provide our credit card info by providing the card number to identify the card and a pin number to prove ownership of the card. When we unlock our phones, we either use touch id or face id to identify that we are both the owner and provide proof of said ownership through a property that is authentic to us.

The above examples are just some ways we authenticate on a day-to-day basis, and they also show a few different implementations of authentication.

1. Method 1: What a user has…

When we badge into the office, we provide proof through something we have. The assumption made by the system is that proof can be shown if the owner provides something unique that only they can have

2. Method 2: What a user knows…

In the case of a login page, it is expected that the user can provide something that only they would know to prove who they are.

3. Method 3: What a user is…

When logging into the phone, we provide proof through something about ourselves, whether that be a fingerprint or our facial structure.

Looking at all these implementations of authentication systems, we can derive some common aspects that are shared among all of them. An auth system seeks to verify that an individual is who they say they are correctly and must be able to do that consistently regardless of when it is used.

What is Authorization?

The second part of the goal describes authorization (also referred to as AuthZ). Once a user has access to a system, now the system needs to determine what exactly the user should have access to. Perhaps they can access everything in the system, though in complex systems this is most likely the case. The question is, how do we differentiate which users have access to what resources? One way to do this is through a role-based access control (or privilege-based access control) mechanism, where a role is a set of actions a user can perform on a resource. Each action that can be performed on a resource is called permission.

A great example of permissions is the access controls on a Google document. The owner has both read and write access + they can make comments on the google document. Now say the owner of a document wants to share the document with others, but maybe they don’t want users to edit the document. The owner can set the permission to “Viewer,”  such that the user can only view the contents of the paper. Now maybe, the owner wants people to make suggestions, they can assign the “Commenter” permission. In this way, the owner is able to control what happens to the resource they own.

Authentication and authorization are two vital aspects of building any secure system. The goal in building a robust auth system should be able to first identify users and verify their identity, and then grant them access to the appropriate resources. It should also be able to detect and prevent unauthorized access attempts and be combined with other security measures for maximum security.