Authentication and Authorization

Author: Christina Tang

Authentication: a cybersecurity process that confirms that a user or user device is ‘who they say they are,’ most often used in the context of the user or device asking for access to resources over a network. Typically paired with an Authorization process.

Authorization: a cybersecurity process that confirms a user or user device is allowed to access the resource they are trying to reach. Typically paired with an Authentication process.

Scope: the range of resources or services that a user or user device has been authorized to access or is seeking to access. Typically must be defined in an Authorization process.

Explainer

This explainer is primarily concerned with generic concepts, not specific protocols or implementations. Examples of current methods will be listed at the end, but their specifics will not be covered.

To talk about authentication and authorization, we need to talk about owners and resources. Authentication and authorization are cybersecurity processes put in place by the owners of resources to limit access to their resources. In short, these processes prompt users to ‘ask for permission’ to access a resource.

A resource could be many things. As users, we would typically encounter authentication and authorization processes at the Application Layer of the OSI Model (Level 7), where resources are typically human-level, such as files, documents, email, a website, an API, or subscription services like Netflix or Adobe.

The owners of these resources need to limit access to these resources for various reasons. For files, documents, or email, the reason could be privacy and information security. For websites or APIs, the reason could be to not waste server resources on non-human bots. For subscription services like Netflix or Adobe, the reason could be to limit access to paying customers only. The number of reasons could be as nuanced and specific as the number of resource owners.

In all cases, however, the owner needs to define which users are permitted, or authorized, to access which resources. These definitions of ‘who’ can access ‘what’ are known as authorization scopes. Then, when a user is prompted to ‘ask for permission’ to access or use a resource, the permission is granted based on the scope assigned to the user. The takeaway is that being granted access to some resources does not guarantee access to all resources. For files and documents, an example of different scoping is Google Drive’s ‘Read Only’ vs. ‘Editor’ access. For emails, logging into your account only permits you to see your own emails, not your friends’. For websites and APIs, different scopes could allow different limits on calls per hour. For Netflix or Adobe, it could be the difference in services provided by different subscription tiers.

Let’s change our perspective back to the user side. In order to access a resource, a user must first prove that they are who they say they are, aka get ‘authenticated,’ and then ask permission to use the resource, aka get ‘authorized.’ Authentication is a prerequisite for authorization because the owner needs to know who it is they are allowing access. Once authenticated, the process determines if the user’s requested resource is within the user’s scope of authorization. If so, the user is given permission, or ‘authorized’, and finally allowed access to the resource.

As everyday users and consumers, we are often supplying various types of credentials for authentication and authorization.

As coders and developers, we will need to implement methods of authentication and authorization when creating applications. If we are interfacing with existing frameworks, these methods can be extremely specific (and potentially poorly documented).

As makers and creators, we may even need to design new systems of authentication and authorization.

Ultimately, these concepts prompt us to think about trust and safety. As we continue to use, implement, and create these systems, we also need to contend with why modern implementations have become necessary, and consider what will be necessary in the future.

Complications

Authentication and Authorization at lower levels of the OSI Model

The explainer above covers exclusively human-level scenarios. The analogy of asking and giving permission is clear with human-created and human-administered resources like files, documents, or Netflix subscriptions.

However, authentication and authorization processes happen at all levels of the OSI Model. Most are hidden from view because A) the resources and permissions in play have more to do with the device’s security rather than a human user’s, and B) the processes are automated.

For example, in the Data Presentation layer (Level 6), where packets of compressed and encoded information is decoded into a human-readable format, authentication and authorization can be found within the encryption methods, such as SSL. SSL’s cryptographic process require a ‘handshake’ to authenticate and authorize encryption and decryption of packets. For more on this, see cryptography [ITP Glossary].

In the Session layer (Level 5), where ‘session’ links are created, authentication and authorization methods are put in place to validate the creation of the session link. They may need to be renewed periodically to keep the link open.

This reinforces that authorization and authentication are generic but important concepts throughout networking and systems terminology. As users and makers, we will rarely need to deal with authorization and authentication in these lower-level settings, but it useful to keep in mind that the terms appear in many different scenarios.

Conflation of Terms as ‘Auth’

Confusingly, ‘authentication’ and ‘authorization’ — both singularly and together — can be referred to and abbreviated as just ‘auth.’ This is a quirk of language, overlapping concepts, and laziness.

Language-wise, both words share the same Latin root, ‘auctor,’ meaning originator or author. This is helpful to think of how we set up authorization and authentication: the creator or owner of a resource is the one giving permission. Due to laziness, they can both be shortened to the same first syllable, ‘auth’.

Conceptually, authentication and authorization are often carried out within a single service implementation. Authentication only becomes necessary when something needs to be authorized, so the ‘authentication’ step is often completed within an ‘authorization’ service, and may not be specifically mentioned. At the same time, some ‘authentication’ services also provide ‘authorization’ as authentication can be the more difficult step.

So you usually only need one term, ‘authorization’, to talk about both processes, and ‘auth’ is just so much easier to say and write. In the above explainer, I tried to use both terms when I meant both terms, so it is more clear when a process only involves one or the other.

If we just want to be more specific with our abbreviations, authentication can be abbreviated to ‘authn’ and authorization to ‘authz’.

Examples of Authentication and Authorization methods as of 2024

Authentication and authorization protocol are constantly evolving to keep ahead of ‘bad actors’ online. As computational power becomes cheaper and access more ubiquitous, older methods are updated or phased out in favor of more secure implementations.

Human Authentication for Digital Accounts

The most common application of ‘authentication’ is in certifying that the right human is accessing the right account.

This type of authentication is often spoken of in ‘factors’. A factor is a piece of evidence of your identity. In the past, single-factor authentication, such as providing your password, was enough to authenticate a user. Nowadays, standards are moving towards two- or multi-factor authentication for increased security.

Single Factor Authentication (SFA) requires one method of authentication, most commonly a username and password.

Multi-Factor (MFA) requires a user to supply two or more factors. See below for examples of factors.

SSO: Single Sign-On allows the use of a single sign-on method to be used across multiple platforms within a single organization. NYU implements an SSO method for many services to its students, such as Google Drive, Albert, and Zoom.

Types of Factors

This list is not exhaustive.

Knowledge-Based Authentication, or Something you know:

  • Usernames and passwords
  • Security Questions
  • Personal Identification Number (PIN)

Possession-Based Authentication, or Something you have:

  • Hardware security keys. See: Yubico
  • Authenticator applications. See: Salesforce Authenticator
  • Personal Access Token. See: Github
  • Passkeys. See: Passkeys.com or Google Passkey. Passkeys are not curently widely adopted, but as of the writing of this explainer (2024) they are regarded as being the next standard for account authentication.
  • One-Time PINs (OTPs) sent to your phone or email. See: your bank, probably

Biometric Authentication, or Something you are:

Application or Use-Based Authentication for Digital Services

As a coder or maker, another common form of authentication is on an application-basis. These forms of authentication are often more automated or computerized.

Authorization Types

Authorization does not have as many common examples, as it is handled more on the back-end by administrators (or ‘owners’ of resources) than by users. Users would most typically handle authorization levels in their account setup. As coders and makers (and therefore administrators), two ways we may encounter authorization are:

  • Identity and Access Management (IAM): See Google or AWS. Provides a central administrative dashboard for managing account access to an application
  • OAuth 2.0. The industry standard for third-party authentication and authorization

References