a good thing!
Our Ultimate Guide to Authentication: Types, Mechanisms, Forms, Protocols and More
These days, ensuring security for internet-based transactions is more important than ever. We know that recent ransomware attacks could have been prevented through the use of more advanced security. For example, in the Colonial Pipeline Ransomware attack of 2021, a compromised password was to blame. We also know, based on research by Microsoft, “your account is more than 99.9% less likely to be compromised if you use [multi-factor authentication] MFA.” Therefore, the types of protection we use for our employee and customer logins is of significance.
Drivers for adopting better authentication extend beyond the business world. In light of recent events, the United States government is now advocating for this as well. In this article about ransomware, we see the President and members of Congress are backing new legislation to formalize a cybersecurity reporting structure and improve the ability to respond when cyberattacks occur.
The way we provide this protection is through the use of stronger means of authenticating users before access is granted to authorized resources and systems. I hope to acquaint you with some basics of authentication, what it is, what types of authentication are available, and how it might be employed within an organization.
Let’s start by defining authentication, which the dictionary describes as “the process or action of verifying the identity of a user or process.” In a cybersecurity context outlined in the Site Security Handbook, we can consider it “…the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular.” Essentially, authentication is the process of verifying that an online user is who they say they are.
According to our friends at Gartner, “Authorization is defined as a process ensuring that correctly authenticated users can access only those resources for which the owner has given them approval.” Basically, authentication is the IT/cybersecurity equivalent of permission to do something once we know who you are. This means authentication is the necessary state for authorization to occur. As an example from our everyday life, let’s use air travel. I need to authenticate my identity by showing an official ID and a boarding pass before I can be authorized to board the plane.
The key takeaway here is that these are two separate and distinct activities from a security/identity perspective. That’s a good thing. By keeping these as separate objects or concepts, it means we can change either one independently, rather than having to recreate everything. For example, changing my password, or even my username, would not necessarily cause an issue with my authorizations as long as there is still a way to provide a common link between the two objects. This is typically done with an internal identifier used to permanently connect the two.
The same concept applies to our authorizations. I can assign my authorization(s) as needed to the authenticated identity and change them as needs, laws, regulations and use cases require from my back end systems; since we have that defined link back to the authorizing identities, there is no need to rebuild everything from scratch.
This brings us to a discussion of the types of authentication we can employ. Classically, there are three main types or factors of authentication:
Something you know. This is typically passwords and PINs, probably the weakest form of authentication out there. As mentioned above with Colonial Pipeline, knowledge of a password with no other protection can have serious consequences.
Something you have. This can be a token of some sort generated via the transaction or an application (e.g., PingID, Google Authenticator). It could also come from a hard token, such as a USB based device or separate code generator (e.g., YubiKey or RSA).
Something you are. This has a biometric component, like a fingerprint, facial recognition or a retinal scan. Biometrics require some sort of hardware, which can limit adoption if the scanners are not portable, accessible or affordable.
Using one form of authentication provides some security. Requiring two factors of authentication (2FA) is the norm and considered more secure. Multi-factor authentication (MFA), where two or more factors are required, is the most secure.
So how do we authenticate a user anyway? What can we actually do to prove we are who we say we are during authentication?
Passwords might be the oldest and most well known form of authentication. It’s not bad as a first factor, providing we use common sense rules for creating and managing them. However, passwords can be compromised fairly easily and should be backed by stronger forms as part of an authentication and authorization process. This is the best known example of “something you know.”
Hard tokens are small hardware devices that users carry to authorize access to a network service. RSA fobs and YubiKey USB dongles are examples of hard tokens. The device itself contains an algorithm, either a clock or a counter, and a seed record used to calculate the pseudo-random number. The devices require the transfer of this code either by entry of a number on a screen or directly via the USB connection (some newer models also require an additional biometric step as well). This is an excellent example of “something you have.”
Soft tokens provide the same services as a hard token, but are software rather than hardware based. These applications typically run on a smartphone and generate a one time password (OTP) for signing on. This leads to some interesting types of integrations including the mobile based authenticators such as those from Ping, Google and Microsoft. They bridge the gap between “something you have” and “something you know.”
Biometrics bring the concept of “something you are” to authentication. Biometric forms of identification are well known in everyday life, like using facial and fingerprint recognition on our laptops and smartphones. Other, deeper forms of biometric authentication, such as retinal scans, voiceprints, brainwave and heart signatures, are gaining prominence as well.
Device authentication is related to soft tokens, and some might even say biometrics. Rather than using the unique characteristics of one’s body, we are gathering unique characteristics of a computer (and how one uses it) to prove authentication. Unique identifiers from the device used to log in, along with observable and recordable behaviors, such as typing speed and cadence, can be used for authentication.
Context-based authentication is probably the most interesting form of authentication in that we look beyond the traditional forms of authentication and focus on how the request is coming through. Contextual authentication collects signals like geolocation, IP address and time of day to help establish that the user is valid. We can look at additional metadata, such as where the request is coming from and whether the IP address is “risky” (e.g., a coffee shop, airplane internet or anonymous networks). After examining the data for red flags, additional authentication methods may be required. Which leads us to…
Utilization of authorization factors during the login process is sometimes referred to as “friction,” which directly affects the user’s overall experience. Security architects and administrators need to balance friction vs. security in almost every aspect of their work. One common way of reducing friction is to remove or minimize the password component, since it provides the most friction and is the least secure (e.g., users typically reuse or use weak passwords). There are times when a simple password or single form of authentication are sufficient. But for some situations we need more. The more authentication factors that we employ, the stronger the protection. When we use all three factors, we achieve a standard referred to as “strong authentication.”
It’s all well and good to understand how authentication happens, but what actually makes authentication work? This is done with protocols, so let’s break down some of the most common ones we see and how they are applied.
Security Assertion Markup Language (SAML) is the grandparent of authentication protocols and still the backbone of web-based single sign-on (SSO). The basis of this form of authentication is the assertion generated between the user, usually referred to as a principal found within an identity provider, and a service provider that allows connectivity to an application or service. The interesting thing about SAML is that it doesn’t actually specify a method of authentication on the identity provider side. It could be a password, MFA, or even be based on a login from an outside service such as Google, Facebook or LinkedIn.
OpenID Connect (OIDC), currently at version 2.0, is ideal for connections between modern applications found on the web and various types of applications that use RESTful APIs. As Single Page Applications (SPAs) become more popular, OIDC is becoming more and more important.
Fast Identity Online (FIDO) is one of the newer technologies to enter the authentication space. The FIDO Alliance has a stated purpose of “working to change the nature of authentication with open standards that are more secure than passwords and SMS OTPs, simpler for consumers to use, and easier for service providers to deploy and manage.” This is commonly the standard that we see when working with operating system based authentication like Windows Hello and Apple Face/Touch ID. FIDO is gaining popularity and interest in larger organizations, but can require state-of-the-art cameras and readers that need infrastructure to maintain and use. This can be a slight barrier to acceptance for use cases in some scenarios.
Here you can see a common authentication flow, which includes checks for credentials and context, as well as a possible request for a second authentication factor if the context is deemed too risky or sensitive.
The introduction and use of multiple forms of authentication ensures we are properly verifying connections as they come into our application spaces. It is especially important that we look at all exposed endpoints and applications to ensure not only is the login experience properly protected, but so are the underlying applications. It stands to reason that even though a user might be already authenticated, requiring additional authentication when accessing resources containing privileged or private information makes sense to protect sensitive data.
This does not mean that the overall security posture and positioning needs to be overbearing. I am aware of security-focused organizations that only require a username and password login every 30 days, but require users to authenticate via an external authenticator app or biometrically daily. This is a good compromise between the “something you know” and “something that you have/are” parameters. The daily routine is flexible, making this friction quite manageable. This model also leaves plenty of room for adding additional authentication for secure applications as discussed above and other avenues of risk mitigation.
When organizations employ authentication factors and protocols in a well-thought-out manner, users can still have excellent experiences while security administrators and auditors know operations are being executed securely. As we have seen, there are a number of ways to provide these services in any organization.
We at Ping see great value in establishing an authentication authority—a centralized and trusted authentication system that allows you to secure and control access to resources across all of your domains, apps and platforms, from public and private clouds to legacy on-premises environments. To learn more, read the workforce authentication authority or customer authentication authority white papers.