Stay up to date with Pomerium news and announcements.
When it comes to access control, authentication (AuthN) and authorization (AuthZ) fulfill different functions as methods to control access. In the modern world, those resources can be sensitive assets, applications, programs, devices, or more.
But what are these control mechanisms and how do they differ?
In short:
Authentication is who you are
Authorization is what you can do
Let's cover the following:
What is authentication?
What are the types of authentication?
What is authorization?
How is authorization enforced?
How do authn and authz interact?
What is authentication (AuthN)?
Just like how a person boarding a plane needs to verify their identity, an organization’s first question when someone attempts to gain access should be: “Who are you?”
Authentication involves proving a user, machine, or application’s identity is who they claim to be. Being able to prove identity is crucial because no organization wants to give access to the wrong user.
What are the types of authentication?
Authentication generally falls into three main categories:
Something you know (e.g. Knowledge-based, like a password)
Something you have (e.g. Possession-based, like a YubiKey)
Something you are (e.g. Inherence-based, like fingerprints)
Demonstrating knowledge is a commonplace method usually taking the form of username and password combinations. While easy to implement and familiar to most users, this is also the least secure method as passwords can be easily guessed, stolen, phished, or even forgotten by the intended holder.
Demonstrating possession is picking up traction in the form of pre-registered mobile devices or hardware tokens (such as FIDO or YubiKeys) for verification. The main benefit of this method is that possession of an item cannot be guessed or phished, increasing the difficulty for bad actors to fulfill the requirements for this method of authentication.
Demonstrating inherence is proving you are what you say you are. This normally takes the form of biometric verifications such as retina scans, fingerprints, or facial recognition systems. While this form of authentication is strong, it risks permanence as biometrics can change over time.
Most forms of access control become stronger by using two or more of the above factors when authenticating, known as two-factor authentication (2FA) or multi-factor authentication (MFA). Effective use of these authentication methods has enabled modern companies and organizations to shift to a passwordless authentication system.
What is authorization (AuthZ)?
Once the system understands who the user is (or isn’t), the next question an access control system asks is: “What are they allowed to see and do?” In many systems, this is the system checking authorization policies to see if a given user has permissions to see or do what they’re trying to access. Permissions are important because even if a person is verified to be a legitimate user of the system, not all users should be given the same level of access or visibility.
For example, your airplane boarding pass might give you access to the passenger cabin of a plane, but it does not give you the permission to enter the cockpit.
Organizations use authorization policies to determine if a user has permission to read (see), write (do), or both when the user is trying to accomplish something. Validation frequency, accuracy, and timeliness are important factors to consider, as well as whether the infrastructure supports that level of authorization enforcement. Unfortunately, most authorization policies also generate a problem for the organization: enforced security with lots of friction can decrease productivity, or authorization policies are ignored in pursuit of productivity which introduces security gaps.
Access control systems need to balance these two competing desires — security and productivity — without impacting either. They accomplish this by having infrastructure and tools to enforce robust authorization policies.
How is authorization enforced?
Authorization policies mean nothing if they can’t be enforced. To do so, organizations also implement a policy enforcement point (PEP) into their access control infrastructure to enforce authorization decisions.
Source: NIST SP 800-207
While the end result of a PEP’s decision is a binary “Yes/No” to granting access, the process for each user to gain the system’s trust (and access) should be explicitly defined by authorization policies. And yes, each user should start with the principle of least privilege and gain access according to trust levels within your authorization policy framework.
That ticket allows you onto the plane but not into the cockpit, an access request with expanded scope. (Source: NIST SP 800-207)
Commonly seen authorization policy frameworks are:
Role-based access control (RBAC)
Attribute-based access control (ABAC)
Role-based Access Control (RBAC)
A user (or their group) is assigned a role with corresponding authorization levels and permissions. This scalable solution means that a user can easily be assigned new roles and gain the equivalent authorization levels, or removed from certain roles and lose those privileges without changing the core individual’s identity.
Attribute-based Access Control (ABAC)
Similar to RBAC, ABAC assigns privileges and access based on the user’s attributes instead of roles.
Read here for a more in-depth description on their comparisons and differences.
How do AuthN and AuthZ interact?
Put together, authentication verifies a user’s identity while authorization determines what privileges they have once verified. The two concepts are simple but difficult to put into practice because many systems aren’t flexible enough to contend with context-aware issues.
An example of a PEP system evaluating a user’s access request would look like the following:
Authentication outcome
Authorization outcome
Organization Reasoning
“They aren’t who they say they are.”
“Definitely not allowed to do anything.”
Denying access to unauthenticated users.
“They are who they say they are.”
“But, they aren’t allowed to do that.”
Denying access to authenticated but unauthorized users.
“They are who they say they are.”
“And, they are allowed to do that.”
Giving access to authenticated and authorized users.
“The user is who they say they are, but the device isn’t registered.”
“They are limited to actions that won’t negatively impact the organization.”
Granting limited access to authenticated and authorized but contextually-problematic users for basic productivity purposes without exposing the organization to security gaps.
The last example showcases why organizations need flexible access control systems to balance security and productivity needs.
A separate post discusses how context-awareness impacts access control systems.
Add Authn and Authz Easily
Pomerium's place as a reverse proxy makes it the top choice for adding authn and authz to any application. Our customers depend on us to secure zero trust, clientless access to their web applications everyday.
