Understanding Authentication VS Authorization

What is the difference between authentication (authN) versus authorization (authZ)? While these two fundamental security terms are often confused with each other, the only real similarity is they both begin with the letter “A” and are linked by an account. In concept, one verifies the account (authentication) and the other sanctions (authorization) the account to perform a task. Because these terms are so fundamental, it’s crucial to understand the difference between them, and the implications for each when the concepts are blended

What Security Frameworks say about Authentication & Authorization

There are lots of frameworks to help you define, organize, implement, and improve security initiatives. A few of the most popular are:

• Control Objectives for Information and Related Technology (COBIT)
• US National Institute of Standards and Technology (NIST) Cyber Security Framework
• International Standards Organization (ISO) 27K

Each of these frameworks details security concepts for funding, risk management, measuring effectiveness, systems hardening, and incident response. One of the foremost challenges all security frameworks face is their complexity. The level of detail can make it difficult to consume.

Additionally, when a superset of concepts like identity management is explored, a bias is normally deep-rooted within the concept’s definition due to legacy technologies like Active Directory and group management. And, if you introduce a modern solution like Azure AD or dedicated identity governance solutions, adopting a new paradigm for identity and account management may conflict with legacy technology and people’s mindsets for operational excellence.

When you add technology like biometrics and user behavior analytics into the concept of identity management, the theory of a security framework can be further blurred, leaving implementations using the same control to solve multiple problems. For example, did you validate the account or the identity, and should it apply to authentication, authorization, or both? While this is not normally a problem, it becomes one when user authentication is inappropriately merged with authorization. To understand why, let’s look closer at the differences between authentication and authorization, as well as examples for each.

Authentication Defined

By definition, authentication (authN) is a login (username for identity confirmation with no degree of confidence) in addition to some form of secret (historically, a password), to establish proof or trust in an identity. It is essentially validation of who you say you are.

Authentication of your identity = login + shared secret (password)

While there are infinite variations of shared secrets that can be used within a login, such as pin codes, passwords, keys, etc., the login itself is generally not a secret and is often guessable for an identity. Confidence for the identity using the account is solely based on knowledge of the shared secret; the username itself does not share the same privacy and security restrictions. This authentication methodology is called single factor authentication. This type of user authentication is a primary attack vector for threat actors because a password is all that is needed to compromise the account.

Here’s a single factor authentication example. If my name was John Titor, my login could be “jtitor” or jtitor@domain.com as my account name is an abbreviation of my actual name. However, a login could also be something more complex, like an employee number, which better obscures a user’s identity and is not necessarily guessable without some form of information to correlate the identity to account username. For highly secure environments, this second approach is preferable, especially for administrator or root accounts. Essentially, you are not able to visually identify the privileges or role of the account simply by looking at the account or username. This is in comparison to naming the account something like “x-admin”. Obscurity is not security, but it often helps and, when defining authN, can boost the security of single factor authentication system by not using a guessable username.

So, in simple terms, authentication is nothing more than proving your identity or your ownership of a given account. The degree of confidence is based on the knowledge of a shared secret that you are whom you say you are. It does not provide permissions, privileges, or access, just confirmation that your identity knows the shared secret for an account. And remember, an identity can have multiple accounts, creating a one-to-many relationship.

Unfortunately, authN is often confused with authZ—even though they are distinctly different from a theoretical perspective. In some computing models, authentication and authorization are blended together and have little distinction in implementation or management. Apple iOS, for example, uses biometrics for both authorization and authentication, and the end-user experience is blurred regardless of the action type. Without first establishing a definition for authentication and authorization, it often leads to confusion between the two and a muddled definition problem.

Authorization Defined

Authorization (authZ) is the next step after authentication. You cannot be authorized to perform a function, have privileges assigned, or perform tasks in a given role, without first being authenticated. Even if you are a Guest in an application or operating system and have no login and/or password of your own, your authentication is assumed to be Guest. Thus, you are granted all the rights and privileges of that Guest. While the login username and password (account) secret are much less relevant, you have still been authenticated and still receive some form of authorization, albeit minimal. Therefore, by definition:

Authorization = privileges (what you are allowed to do) + Authentication

Authorization can be defined as the right to perform a function based on your authentication. Your identity and its associated account are granted privileges to perform specific functions and may also be explicitly denied or lack the privilege to perform other functions.

Privileges can be assigned within an application, an operating system, or some part of the supporting infrastructure. Privileges may also be assigned within an identity or privilege management system that is controlling it. In order to manage privileges at scale, using a dedicated system, like a privileged access management (PAM) solution is always preferred.

Authorization increases in complexity when an asset is shared among multiple identities, has granular privileges, and interoperates with other resources. This, in a nutshell, is why a blurred line is loosely acceptable for devices like Apple iOS. These devices typically have one owner, one user, one operator, only two levels of user permissions (normal user and parental controls), and operate with trusted communications based on the primary authN model (pin, fingerprint, or facial identification). The need for granularity in authZ is moot because, typically, only one user is ever operating the device for its entire lifecycle.

As an addendum, grouping like privileges together creates the foundation of a Role. When a Role is assigned to a group of accounts, the Role is providing authorization for that group to perform those functions in lieu of being applied to individual identities one at a time. For example, a Role might be loosely defined by your job title and all other employees that have a similar title like accountant or engineer. Each role would have different privileges than another role. Grouping them this way reduces complexity.

Protecting Identities with Proper Authentication & Authorization

Applying the same mechanism for both authN and authZ can lead to significant issues relating to the integrity, controls, and oversight for a given process. Widely accepted security best practices recommend separation of authentication and authorization, yet exceptions do exist, like your mobile phone.

A breach or weakness in one model leads to a breach or weakness in the other. While some vendors have designed high levels of security into their authentication or authorization solutions to minimize the risk, most computing environments should avoid using the same technology for authentication and authorization. A compromise in one can lead to a compromise in the other.

Just because you have been authenticated does not mean you should have authorization. Those privileges and permissions should ultimately be decided upon using a separate process and a separate layer in the security stack. Even in modern “state-of-the-art” computing environments, we often see the same lack of separation when a Single Sign-On (SSO) solution blurs the line between initial authN and the automatic authZ within a managed application. Multi-Factor Authentication (MFA) solutions can help mitigate this risk by requiring a second validation for privileged or administrative activity to help keep them separate. And finally, applying the model of least privilege can reduce the amount of privileges to further minimize the risk. However, the best practice remains keeping them separated and using different mechanisms to validate each one.