Despite the similarity of the two terms, Authentication and Authorization are two distinctly different processes in the field of Identity and Access Management (IAM). In short, Authentication is the act of verifying the identity of a user, while Authorization is the process of defining, granting, and enforcing specific privileges of a user.
What is Authentication?
The act of validating the identity of who a user claims to be is referred to as Authentication, often abbreviated as AuthN. There are numerous strategies utilized in modern computing systems, some of the oldest (not necessarily most secure) being PINs and Passwords. This is the “I” in Identity and Access Management (IAM). At the core of all Authentication mechanisms is a secret that only the correct end user would know, or a function that only the end user can complete.
Keep it Secret
Exclusively known secrets, or passwords, are perhaps the oldest form of authentication. They far predate modern digital computers and can even be found in ancient historical literature. The factors contributing to the security of a password are primarily its uniqueness and the assumption that it is a secret known only by the true user. Strong passwords tend to be long, high entropy strings of characters. For example, a 40 character string of randomly chosen letters, symbols, and numbers would generally be a very secure password, provided that the end user keeps the password a secret.
Modern Authentication Mechanisms
Besides passwords, new mechanisms now exist that are commonly used to verify the identity of Users. Most modern smartphone and mobile computer devices employ Biometric Authentication in the form of fingerprint scanning or 3D and/or Infrared Facial Recognition. In addition to biometrics, many websites with highly valuable data (such as financial institutions) also employ Multi Factor Authentication (MFA). This is a strategy where two or more Authentication mechanisms are implemented in serial, and the user must validate with both methods. If either method fails, the User is not authenticated. The first step in MFA is often the traditional secret password. Common second step authentication strategies used in MFA are time expiring emailed or texted PINs, or dedicated MFA applications such as Google Authenticator or Duo Security.
Single Sign On
One further strategy that was first employed in enterprise workplace environments but has now made its way even into consumer social media applications, is Single Sign On (SSO). This is a strategy that allows a user to authenticate their identity through a cryptographic “handshake” with a different application that they have previously proven their identity to. An example of this is when applications offer the option to “Login with Facebook,” or “Login with Google.”
There are open source standards to implement this strategy, the most common one being OAuth.
While SSO offers convenience to the end user, it comes with its own set of unique attack vectors. In particular, SSO is vulnerable when a weak password is used on any of the SSO linked systems. If an attacker gains access to anyone of these applications, then they can often exploit SSO to gain access to all other services the User has granted an SSO “handshake” to. As a matter of fact, compromising a weak password or application in SSO connected platforms is one of the more common attack vectors organizations are exposed to when challenged with keeping data secure. This is why SSO is often coupled with MFA, especially in consumer applications where weak or non-unique passwords are common.
What is Authorization?
Once a User is Authenticated, the concern of the IAM administrator is on to the next challenge: authorization. Upon verifying their identity, Users are granted specific “rights,” which typically means either read or write access to specific data.
Granularity of Rights
The granularity of read and write access can vary widely, with the most permissive being “root” or “superuser” access, where the user has write access to the entire Data Repository. On the other end of the spectrum of granularity, a User may be granted only read access of certain rows. For example, the end user of a mobile banking application has only read access to a small number of rows in a data repository specific to their account, and zero access to any rows not joined by their user id. A bank that were to allow an end user write access to their own data would not be in business long, as users could write higher balances in their accounts whenever they please! Similarly, it would be a security catastrophe if a bank were to allow any end user to read all rows in the deposit database, as each user could see the balance and transaction data of all other users. One can easily see just how complicated and these authorization policies can become, and how critical it is to enforce them correctly. If an application layer has access to financial or medical data, that application had better enforce the policy correctly with every single query!
The management and implementation of the policies that determine the authorization users are granted is the “AM” in Identity Access and Management (IAM).
Anonymous Read Authorization
Authorization can also exist without Authentication. For example, all anonymous users on the public internet are granted read access to Google Search results and the contents of The Weather Channel website. However, if a Google User authenticates into the Google SSO connected universe of applications, their read access is augmented with both read and write access to a whole new set of data, such as their browsing history and emails.
Policy Enforcement in the Application Layer
In the context of a modern web application, the Application environment is granted full read/write access to an entire database. As a result, it is up to the skill and care of the software engineers building the application to enforce the Authorization Policies. This blanket access to an entire data layer is not too unlike the attack vector of SSO, where a single Authentication to an application can grant access to all connected applications.
In the above example of Google’s SSO connected universe of applications, a critical attack vector exists in the application code. It is all too often the case where the backend application environment is granted full read and write access to the data layer. Hypothetically, an application server that serves information to anonymous users on the public internet may have read and write access to privileged data that should only be granted to authenticated users. As a result, it only takes a single implementation error by a single software engineer, or an outdated web framework, to incidentally expose a compromised API endpoint that can be used to exfiltrate an entire database. Specifically, this is the class of vulnerability that was exploited by hackers in the catastrophic 2017 Equifax data breach
Enforcing Authorization in the Data Cloud with Cyral
Organizations in today’s cloud native environment face critical challenges whereby they must build and rapidly deploy agile solutions, yet simultaneously enforce data authorization policies with more data than ever before. As the cloud environment becomes more and more diverse with a mix of microservices, applications, and third party platforms accessing an organization’s data, it has become more critical than ever before to move authorization out of the application layer and into the data layer, itself. To learn how Cyral’s patented technology can help your organization make this critical transformation, be sure to request a demo.
