Today everyone is familiar with the concept of usernames and passwords as a way of logging into a website, but where does this fit into the larger picture?

I've recently been digging into "auth" for my own side projects and thought I'd throw together my musings into a mini-series. In this first part, I'm going to dive into some of the core definitions that surround "auth".

So what do I mean by "auth" (and why do I keep using it in quotations 🤔)?

"Auth" by itself is not actually a real word but is commonly used as shorthand for 2 distinct processes: authentication and authorisation.

Authentication

Like any good blog post, lets start with a definition courtesy of Google. At it's broadest, authentication is:

the process or action of proving or showing something to be true, genuine, or valid.

It's actually quite important that when we think about authentication that we hold this broad definition as this type of process appears everywhere in many different forms, and although many of these forms may overlap, it is important to be clear about exactly was authenticated.

Let's consider the example of opening a company bank account. In this process you'll be asked to provide your personal details, official documents that cover various parts of these details, and details of your company.

When you first provide your personal details, the bank has no way of knowing (aka authenticating) that the details provided are true, so they will ask for official documents that they can use to verify the details you have provided. You've likely come across this before in the form of "100 points of identification" or a Know Your Customer (KYC) process.

Before the bank can use these documents to authenticate the details you have provided, they will also need to verify the authenticity of the documents. This process can take many forms depending on what documents were provided, including:

• Cross checking the document details with the organisation that issued the documents.
• Inspecting security features of the document to ensure they are not fake reproductions.
• In the case of documents provided electronically checking the file metadata and the image itself for signs of alterations (aka has it been Photoshopped).

Once the documents are authenticated, focus can be shifted to the personal details you provided and ensuring that they match the documents.

Finally, the bank will want to ensure that the documents provided are actually for the person making the application. Generally this is done by ensuring that at least one document provided has a photo and signature that can be compared to the person standing in front of them.

At this point the bank has only authenticated the identity of the person they are interacting with. They will then need to repeat this with the company details provided (which may include verifying the official company documents provided).

Finally the bank will need to verify that your are authorised to act on behalf of the company. For example checking that you are a company director, and that the details that you have provided match those of the company register.

In this example there are approximately 6 different authentication processes (which may be repeated e.g. for multiple documents) each of which is for authenticating one type of thing.

Something interesting that comes from the definition of authentication, is the idea that authentication is some kind of binary process. However in my experience this is not always the case. What is far more common is for an authentication process to reach some level of confidence based on needs, practicality, and risks.

In the bank account example, the level of confidence required is going to be very high due to legislative and regulatory requirements placed on the bank.

On the other end of the spectrum, you have a process such as subscribing to my blog. When you sign up you will provide me your name and email address. The authentication process that is completed is a link being sent to the registered email that must be clicked. This verifies that:

1. The email address exists because it can receive email.
2. The person that entered the email address also has access to that email address because the link was intentionally clicked.

However in this process, it is entirely possible that:

• The name provided is a fake name, because this was not authenticated at all.
• It was not a person but a machine that signed up, because I don't have strong bot prevention.
• The person who started the process was different to the person that clicked the email link, because all I know is that the link was clicked.

This is entirely acceptable for me, as I have no need to ensure that your name is your official name, nor do I care if you are actually a robot. All I really care about from an authentication point of view is being able to show that an email intentionally subscribed to my blog and thus I am not breaking anti-spam laws and requirements by sending you emails. My confidence in the details provided is very low, but still just enough for my purposes.

Another interesting trait that occurs when authenticating in the real world is that most authentication is used in a highly transitive manner. Once an authentication process is complete, we will generally find other ways to re-establish trust without following the original process.

To continue with the banking examples, once you verify your identity with your bank and have a bank account created, they will send you a bank card to your (authenticated) address, and potentially issue you with a username and password to use with online banking. Now when you walk into a branch you simply need to provide your card or when using their website provide the provided username and password. These new "things" are enough for the bank to authenticate you as the person who opened the account.

Although transitive, the level of confidence the bank places on these mechanisms is a lot lower than their original confidence in who they are dealing with.

In response certain processes may require different forms of authentication. For example changing certain details on your account will require visiting a branch and providing government issued ID along with your bank card.

At other times the bank will use after-the-fact systems to correct actions when the authentication process was completed, but failed to properly authenticate the actor. This is where most security systems detecting "anomalous behaviour" will come in.

Identity

Identity is about establishing facts that we know about a singular "real" entity. In most cases we are particularly interested in the identity of "natural persons" (humans), but often extends to legal entities (companies, trusts, etc), or even physical objects (e.g. device serial numbers).

Although the amount we know about an entity and the confidence we have of that information is heavily reliant on authentication processes. they are not the same.

This is particularly important in the context of privacy and the laws surrounding it. Both the Australian Privacy Act and the European GDPR have provisions for allowing persons to interact with you in an anonymous or pseudo-anonymous manner. In order to meet these provisions but also ensure the integrity of your own systems you may need to be able to authenticate that you are interacting with the same entity, without establishing the identity of that entity.

Most websites are actually examples of this wherein you can signup using any username you want and as long as you can provide the password associated with that username the website won't care about your identity.

This leads to a common and important to understand practice of having different levels of requirements for knowing the identity of an entity.

For practicality sake, it is often easiest to start from a base of little authenticated information about an entity, and then increase the requirements based on the risk or external requirements for an action.

For example, to sign up to a website may require no authenticated identity information. However when you now want to make a purchase your credit card information will need to be provided and authenticated with your bank to allow the purchase. However providing correct credit card information does not prove that you are the same person as the one issued with the credit card, so if you attempt to make a very large purchase the website may require you to prove more of your identity.

Authorisation

Authorisation is the process by which we check if an actor can take a given action. Typically this is where you will encounter permission systems or Role Based Access Controls (RBAC).

Whilst we usually think of authorisation occurring after authenticating the identity of an actor (e.g. by having them login), it is not a requirement and authorisation is regularly used in unauthenticated scenarios. For example a website maybe let anyone access it, but may "rate-limit" the IP address to a certain number of requests an hour, or may use "geo-fancing" to restrict which countries can access it.

It is also common for authorisation to depend on the level of trust we have for how a request has been authenticated. When using internet banking you have likely encountered the scenario that in order to transfer funds to an account already in your "address book" you simply need to login, however when attempting to transfer funds to a new account the bank will require a generated code (e.g. via text) to be entered to increase their confidence in that the request is actually coming from the identity associated with the account.

Sessions

Sessions are probably the most common form of transitive authentication. Most web protocols are designed to be stateless - that is, there is no data kept between each request. This is problematic because a large amount of what we want to do on the web relies on the website we are using to know who we are.

We could provide our username and password on every request, but this would get very tedious very quickly. Even more so if you consider forms of authentication that aren't so easily entered such as SMS codes.

To overcome this the concept of sessions was developed in which a web server could authenticate you once using your "proper" credentials, after which it would provide you with some data that your browser can use to authenticate subsequent requests.

We'll be exploring Sessions in greater detail later in the series.

Fin

In the next post we will be diving deeper into how authentication occurs.

In the mean time, you may want to take this knowledge to break down your own authentication and authorisation processes.

Part 2 available now.