Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Understanding Authentication VS Authorization

October 19, 2020

  • Blog
  • Archive

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.


Whitepapers

Privileged Access Management (PAM) Checklist

Morey J. Haber

Chief Technology Officer and Chief Information Security Officer at BeyondTrust

Morey J. Haber is Chief Technology Officer and Chief Information Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four Apress books: Privileged Attack Vectors (2 Editions), Asset Attack Vectors, and Identity Attack Vectors. In 2018, Bomgar acquired BeyondTrust and retained the BeyondTrust name. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. Morey currently oversees BeyondTrust strategy for privileged access management and remote access solutions. In 2004, he joined eEye as Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Up next

From October 15, 2020:
BeyondTrust CMO Liz Shulof Named in the “Top 100 Women in Cybersecurity 2020”
From October 23, 2020:
IT Security Leaders Share Bone-Tingling Cybersecurity Tales & Reveal the Cyberthreat Hobgoblins that Haunt their Sleep (Interview Transcript)

You May Also Be Interested In:

Webcasts | February 24, 2021

Your PAM 2021 Blueprint: Securing Privileged Accounts for On-Premises and Cloud Assets

Whitepapers

Evolving Privileged Identity Management (PIM) In The 'Next Normal'

Webcasts | January 21, 2021

Welcome to 2021: A BeyondTrust Global Partner Update

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.