Authentication vs Authorization

Examining where they meet, where they diverge

For those of us long-timers in the identity and access management space, there are multiple phases to the process of capturing and enabling a user. There’s the activity that takes place on Day Zero, when the new user is still an unknown. They have to be brought into the family, but only in a secure manner. They must be identified, verified and proofed. In other words, either a person or a process (or combination) must examine the information provided by that user (who at that point is merely an applicant) and determine if they are allowed in the door. Once this verification takes place, the user is then provisioned to the digital assets which they are allowed to access.

All of this is essentially Day Zero (although it could take a little longer for approvals to go through) and the user is given a gold star (assuming that they are), they are then subjected to two more vital processes, which take place in tandem with each and every trip to the site in question (company portal, banking app, social media site, whatever). Let’s talk about those two processes. These are authentication and authorization.

They are the subject today. Authentication and authorization are often confused, but most assuredly they are different things, and in fact one prefaces the other (after itself being set up by the aforementioned verification process, which we’ll also expound upon). It’s not just the nerds who contemplate the question of authentication vs authorization.

Both are critical to secure, efficient, and friendly interaction between users and their digital assets. They are also critical to both user and enterprise. Let us pull them apart, to see where authentication and authorization overlap and where they diverge.

It’s not a matter of authentication vs authorization. They go hand-in-hand. Neither truly has purpose without the other. One feeds the other.

In brief … authentication is the act of validating that a visiting user is a trusted entity, someone who was previously verified and granted access. Authorization is the subsequent process of validating which access rights that authenticated user has and allowing them to get where they’re allowed to go. Not to say one’s access can’t change as new apps are added, old apps are retired, and people’s titles change. But in general, authorization occurs when a trusted person walks back in the door and wants their stuff. Welcome back to the club, here are your rights in these places and portals.

As we progress through this topic, let’s also sub-divide people who must be authenticated and authorized. They are

• Consumers
• Employees

We can further divide employees into full-timers, contractors, vendors, etc., or the full contingent of individuals who work inside the firewall. Not only do those two general categories of users have different requirements they must meet, the enterprise treats them differently for the sake of motivation. But classes of user want a great user experience, but for different reasons. We will cover all of this.

Authentication and Authorization – Together

Authentication and authorization are both completely necessary to the proper interaction of users and their assets, from Day One and beyond, as specified by the activity on Day Zero.

There is no use for one without the other, at least not in the transactional world. There is no authentication vs authorization. If a system requires authorization, that means users will be accessing digital assets that have at least some value, and therefore users must assert their previously registered identity before achieving that access. In fact, before authorization can take place, the user must prove who they are via authentication. And you can’t authenticate someone who hasn’t previously been verified. After all, when they log in, they are presumably doing so in order to access the things they’ve been provisioned to.

Another reason authentication and authorization are looked at separately, besides the functions they perform, is that they are often set up by different parties within an organization. HR and LOB owners work together to determine who gets access to what. Authentication is more often than not is accomplished by IT. The technologies for the setup are different as well. Onboarding and provisioning require proofing data and processes which prepare the user for authorization, while authentication is done through single sign-on tech.

Together, these technologies enable users to get where they need to go, while enabling companies to secure the user journey, for everyone’s benefit. So once again, we’re not talking authentication vs authorization. We’re talking teamwork, of technologies and processes.

But First … Who are you?

Before authentication and authorization can occur, a user must be identified. I can’t give you your access rights until I am sure I know who you are. This is done through a process called identity verification or identity proofing. Just as there is no authentication vs authorization, there is no authentication vs verification, and no authorization vs verification. They all follow a logical set of steps.

Verification of employees is easier, since they must be identified initially just to get the job.

Verification of consumers is a very different thing. There is no pre-vetting as with employees. Consumers are registering for bank accounts, social media, email, payments apps, rideshare, and any number of the many thousands of apps available. They provide whatever data is required. Some apps require very little data from applicants, since there may be no transactional nature. Some free emails only require a phone number for validation to prevent a single person from opening a large number of accounts.

But for financial transactions, the requirements get much steeper. In the US, for example, the (poorly-named) Patriot Act requires any financial institution to identify users before allowing them to move money in any direction. This is a good law, although it was originally designed to prevent the funding of terrorists, for which it’s never been used. Instead, it helps combat money laundering and various other types of fraud. Users are often required to provide name, email, phone, date of birth, physical address, Social Security number, and possibly other data points in order to accomplish proofing before they can establish an account. Once proofed, the user can be provisioned to those things that they will later be duly authorized to interact with, once they’ve authenticated.

There’s no authorization vs verification. One feeds from the other. It’s like this:

• Verification says, this is the right person
• Authorization says, these are the access rights I’ll let that person have once they’ve signed in for the day

Workforce Provisioning

Once proofed, employees must be provisioned. This means granting them rights and roles that are appropriate to their position. This may mean they are put into the company directory, the HR system, and any other appropriate system of authority. Employees are subject to Role-Based Access, or RBAC, which says that privileges are granted relative to each user’s role. Think of roles as containers. They specify that if someone has a particular role, they can access everything in the container. These items can be specified in ways such as:

• URLs
• Sub-directories
• Applications
• Databases
• Particular database tables
• Commands (e.g. DROP TABLE)
• Methods
• Files or file types

Provisioning a user to a role or set of assets will later enable the authorization process. I’ve said what they can have, and once they log in, they can have it. Simple.

Everybody inside a company starts with an Employee role, so that by default they get email and file shares. But after that, it gets more specialized. For example, Payables personnel can access the AP system, Receivables can access the AR system, but the CFO can access both, plus the General Ledger. Accounting can view salaries and expenses, while HR can see more personally identifiable data. And so on.

It’s a best practice to assign access rights to a role rather than a person. Roles can be built around security and productivity, and while they can change with the requirements, they tend to be far more stable than the people who occupy those roles. So when a person enters the door, they are assigned a role. There may be multiple people sharing that role, so when the access rights of that role change, it’s far easier to change the role rather than the people, and those people inherit the changes.

RBAC is a fantastic way to manage access. But setting it up is far from trivial. Organizations spend plenty of budget and time evaluating what kinds of people need access to what kinds of applications and data, then building out the systems necessary to grant and enforce those rights. It is also common for companies to review those access rights on an annual basis, to ensure that each role still contains the correct access points for the role holders, and also to ensure that the right people still have only those roles they need. This process of periodic review, typically performed by Line of Business managers who presumably know what access is necessary for their respective departments, is called re-certification. If during this process the access rights within a role change, then all employees currently holding that role see their access automatically change.

When it comes to provisioning within an enterprise, another best practice is Least Privilege. By default, you get NOTHING. Each user must be specifically granted even the most mundane access rights (again, such as email).

Provisioning within the workforce is critical for another reason. If an individual’s identity is stolen, their credit history, bank account, reputation, contacts, and other information can be compromised or damaged. But if an internal, privileged user’s account is breached, this could affect, for example, all customers of that company. Privileged accounts are the conduit for the worst known, most damaging hacks in which millions of consumer identities and their data have been exposed. Ransomware attacks are often the result of compromised privileged accounts. Therefore, it is critical that these internal roles are granted for only the most necessary access. If nothing else, it can segment access and therefore limit the damage in the event a breach occurs.

Consumer Provisioning and Authentication

The provisioning of consumer, or customer, accounts is often much simpler. There are typically fewer roles among consumers. You’re my customer, or you’re not. But even consumers can be categorized, affecting their access. Take into account gold, silver, platinum customers who can access advanced features of a website, relative to their status. They may purchase more advanced status to begin with, or earn it through activity. Authorization may be delayed based on the interim between application and verification. Some enterprises conduct searches for duplicates, they perform background checks, they look for traces of bad behavior such as money laundering or undesirable associations. Provisioning then grants consumers the ability to conduct business, send messages, buy/sell assets, move money, do their banking, etc.

One last note on provisioning: before even classifying people and roles, it’s necessary to classify the assets they will later be authorized for. As in, which assets are common to all, which are sensitive, which are eyes-only for certain departments of lines of business, etc. This is often done to even the most granular levels, such as which columns in a database can be available to which users or applications. Within a medical facility, the billing department can see what’s owed and who owes it, but they may not have access to a patient’s entire medical history.

Once again, provisioning sets up authentication and authorization, which then go hand in hand. Now that we have proofed and provisioned a user, they can be authenticated. Or rather they authenticate themselves.

So there is no authentication vs authorization. Nor is there authentication vs verification. Let’s add to our previous enumeration:

• Verification says, this is the right person
• Provisioning says, these are the correct access rights for this right person
• Authentication says, this person can come in
• Authorization says, now that the person has come in, here are the things they can access, based on the previous provisioning

Authentication – How does it work?

Authentication logically precedes authorization. Once again, there is no authentication vs authorization. The former says, “give me the right information and you can come in.” The latter specifies, “now that you’re in, here’s what you get.”  In other words, authentication is how you log in, to use a term that is universally known.

Authentication can take many forms, and even combinations of them. Name and password are everywhere. But there is also step-up, such as when there is enhanced risk. This can be Knowledge-Based Authentication (KBA) in which the user is asked to answer security questions. These can be previously agreed upon questions that the user has already provided answers to. Several years ago, a major political candidate had her email account hacked when a prankster clicked on her “Forgot Password” link and was able to answer her ridiculously simple questions, with the answers all easily found on Google. One way to defeat this is to provide non-aligned answers, such as “When did I meet my spouse? Blue.”

KBA can also be more randomized. The IRS has employed KBA using answers from data brokers. The questions can be very tough, since they delve deep into a user’s past and ask things such as “what was the amount of your first mortgage,” or “which of these was a past phone number.” Hackers may harvest this data from the dark web and be more able to provide those answers than the legit user.

Another option is One Time Passwords (OTP) or PINs. These are typically sent through email or SMS, allowing a user to initially register, or to recover lost access. The biggest problem with these is when they are intercepted.

Another way of authenticating is through certificates or other assertions. SAML (Security Assertion Markup Language) is a long-established protocol for federating identity across domains. If two or more domains have an established trust between them, then a user who authenticates in one domain may have automatic access to the other domain(s).

Before we begin here, let’s call out a major point of consideration. Just as with authorization, there can be a huge difference between employees and consumers when it comes to basic authentication. The requirements can be very different, for very different reasons, which we’ll cover. But here is what is universal: the need for a great user experience. Organizations want to provide a secure-yet-friendly UX for both consumers and workers. We will examine that.

Consumer Authentication and Authorization

This is an easy one. If you make authenticating difficult, users will take their business elsewhere. At the airport, travelers want their planes to be safe, but they also want to get through the security line quickly. It’s the same desire online. Keep my digital assets safe, but don’t make me jump through hoops.

There are far too many options for online commerce and communication to take the chance on driving away customers.

Usernames and passwords are still the default. But 75% of all breaches result from compromised credentials. If you rely solely on something you know, well, somebody else can know it, and pretend to be you.

Face id is another default in the age of personal devices. My smile gets me into my phone, which then gets me into my apps, because I’ve installed my credentials into that phone. But that means if someone takes my phone, they have options for breaking into it and now they’ve got access to those same apps. The same is true for desktop machines.

Biometrics are taking hold across a number of consumer apps (although not fast enough). If a thief can known what you know and hold what you held, meaning steal your credentials and your device, they can’t steal who and what you are. Fingerprint, voice, and face are still your own. Of course, even these face increasing challenges.

Deep fake voices can be easily inserted, or injected, into an authentication scheme. I turn on the microphone and play a sound that is my AI-generated equivalent of a previously-registered voice. Even voices are reduced to mathematical models.

Fingerprints are a great biometric modality, but the issue there is availability. Apple has deprecated fingerprint scan, meaning the largest provider of personal devices no longer supports this method.

Facial biometrics are still the best option. But what about AI-generated faces, you ask? The trick there is injection. Liveness detection is the process of verifying that a presented face is not a picture, a screen, a person wearing a mask, or something else other than a live person. NIST dictates a standard for this type of detection, to prevent what is called a presentation attack, or the presenting of a fake face.

Face ID on one’s personal device is a good option for localized authentication, but what is that device is lost or stolen? Now that access is on hold until a new device is requisitioned and enabled. New phone, new face registration. And if a thief breaks into a phone, they can install their own biometric. This is why having a biometric registered in the cloud allows the user to recover their access regardless of the device. It also defeats the thief who steals and compromises the device.

Workforce Authentication and Authorization

Even though employees really have no choice when it comes to adhering to company requirements for secure authentication, making the process easier helps productivity and adoption. The less time employees spend just trying to get into their accounts in the event of a hiccup, the more time they have for doing their jobs.

When confronted with a day-to-day hassle, even employees will try for a lower center of gravity, i.e. they will look for shortcuts. So, a better user experience also means faster adoption and better adherence to policy.

While many organizations still have a username-password policy, over three-quarters of US companies have adopted or plan to adopt multi-factor authentication (MFA) in the next 18 months.

A good workforce authentication scheme also includes single sign-on (SSO), meaning once an employee has logged into the enterprise, they don’t need to sign in to every single company app ala carte. Because of the advanced responsibilities and liabilities of having corporate access, these kinds of authentication platforms are usually more robust than simple consumer login.

Authorization – How it works

Once again, authentication simply says, this person has provided the right signals in the right way to be recognized as a valid user on the system. But it’s not a matter of, “Hey, c’mon in, you can eat anything in the fridge.” Once authenticated, the user is subject authorization, which enforces what access rights they have. As mentioned previously, they will be able to consume from the container of access rights granted them during provisioning. Authorization policies typically enforce roles, but could also work off things such as location, originating IP address, SAML assertions, or certificates. An assertion such as a SAML ticket, issued by an authenticating domain and passed on to another trusted domain, may include authorization information specifying what the user can access in that second domain.

Authorization can enforce which URLs, directories, apps, databases and tables, methods, files, or other assets the user can access. And these can be a function of the role or roles the user was assigned during provisioning.

Authorization can also retrieve, in real time, user attributes from the user directory. There may be values inside the user profile that specify, for example, enhanced status, such as gold, platinum, or silver. Employee versus contractor. Full time versus part time worker. These kinds of attributes may have policies attached to them which the authorization process enforces. Changes to these attributes, just like changes to roles or policies, may result in changes to what the user can access. If the user had certain access on one day, but their status has changed, then authorization should pick up on that immediately upon authentication.

To reiterate for the umpteenth time:

• There’s no authentication vs authorization
• There’s no authentication vs verification
• There’s no authorization vs verification
• They all serve a purpose, in a particular order. Verify, authenticate, authorize.

Best Practices for Authentication and Authorization

We have covered some of this already, but let’s recap the best practices for both authentication and authorization. Have a solid posture on both processes is essential for both user and provider.

For the user:

• Create strong passwords
• Insist when possible that your online services provide strong authentication options, such as biometrics
• Don’t rely on your personal devices as your root of trust, since they can be damaged, stolen, or infiltrated
• Don’t click on links in strange emails or texts, and in fact even a co-worker who has been hacked can send you dangerous links

For the enterprise:

• Utilize authentication processes that don’t rely solely on passwords and/or devices
• Enforce strong passwords
• Provide multi-factor authentication options, including biometrics to combat stolen credentials and stolen devices
• Train users on phishing and smishing attacks
• Use role-based access in which roles contain granular rights, and people are assigned roles, rather than directly assigned rights to individuals
• Assign owners to those roles, who will verify the access that is correct for those roles, and who should be assigned those roles
• Annually or semi-annually, review access rights and roles, as in if they are appropriate, and who has been assigned those rights and roles

Verticals / Industries / Use Cases in Need of Strong Authentication

There are many use cases for biometric authentication, in order to absolutely validate identities, including against deep fakes, the new but very real boogeyman of the identity industry. You could say that social media is not that big of a deal, but fraudsters use Facebook and other such platforms all the time to spoof real (or synthetic) people in order to run their scams, including fooling the friends and relatives of those real people into sending cash, wire transfers, crypto, gift cards, and other assets. Social media is also the breeding ground for romance scams. Online dating? There you go.

But there are other, more industrial strength cons that strong authentication can help fight.

• Money transfers. This can originate from the enterprise, in verifying the identities of both sender and recipient, and in some cases save people from their own gullibility. “That guy asking for that cash is not who you think he is.”
• Is that your correct driver? Oops, it’s not, and this guy’s not bonded, certified, or insured. Is that your correct passenger? He’s going to carjack you.
• Workforce in general. Is that the right service provider showing up, or was he hungover, and he sent his cousin, who has not been properly trained, isn’t insured, and could cause a big problem? Prevent what’s called “buddy punching.” Biometric authentication keeps the wrong person from showing up with somebody else’s badge.
• Banking and other financial services. Willie Sutton the bank robber was asked why he robbed banks. His reply? “That’s where the money is.” Financial institutions are still the major target or people claiming to be legit account holders.
• Call centers. Don’t just reset that password over the phone. Send the caller a link allowing them to authenticate themselves. You’re helping them, but not just giving it away. The social engineering of help desk staff has led to some huge, costly attacks.
• Did you know that hernia operations are among the most stolen procedures? Scammers regularly get undeserved treatments and drugs, and love to steal other people’s health records that are loaded with useful information.
• Notary services. Since covid, a lot of notarization is done remotely.

Finding Providers for Authentication and Authorization

How do you find the right technology? There are a number of software companies who provide provisioning products and services, meaning that when someone is onboarded, they can be instantly enabled across the multiple applications they need access to in order to do their business or their job. There has been a measure of consolidation in that space, however, with multiple providers now owner by the same hedge funds.

When it comes to provisioning, one of the most common hassles is, how well does a solution connect to all the many applications under my umbrella? Can it talk to my HR system, accounting, timekeeping, help desk, productivity tools, and so on? Does it support basic protocols such as OIDC and SAML and SPML?

Authentication and single sign on are also common tools, with lots of options. They often provide name and password, that’s easy, but then they too often have to plug in things like OTP or device-based options. Many of these will also provide authorization, but here’s the rub: because so many companies have not actually made use of the authorization tools inside these solutions, various providers have deprecated that functionality, leaving companies to rely on individual applications to enforce policies regarding who can access which pages or click which buttons. This makes an IT department’s job much harder.

Not many of them provide biometric authentication, and so it’s common for them to partner with biometric companies. But when it comes to biometric, there’s another thing to pay close attention to. What are their metrics? How often do they confirm the wrong person? How often do they fail the right person? Biometrics is a technology unto itself. Anybody can validate your password against the hashed equivalent in the directory. But validating a facial biometric against a live person, and also validating it against a physical id, while simultaneously ensuring that physical id is legit and not a picture of one … these factors are not trivial.

The authID Solution for Authentication

With authID, the approach is not to pit authentication vs authorization. Our platform They go hand in hand. But remember that authorization truly only exists to enable authentication. I only want to know who you are so I can let you in, safely for both parties, each time you need access.

We provide the absolute market-leading tech when it comes to validating:

• The legitimacy of a physical id. Is that a real driver’s license, or a picture of one? Has it been tampered with? Is the person on it a real person, or is it a deep fake of a fake identity? We cover almost 14,000 ids from around the globe, in a variety of languages, to ensure that a presented id is real, legit, and comes from the source it says it does.
• The face. Is it a real person? Is it someone wearing a mask to fool biometrics? Is it a picture or a screen? Is it a deep fake? Or is it a legit, live person, in real time?
• Do the physical id and live person match? Does the image on the id match the live person’s face?

We enforce rigid standards of liveness for both id and individual, to make sure we know who we’re dealing with. Only then will we go forward with onboarding. And why do we onboard? So that the individual can successfully and quickly authenticate each and every day with only their face.

We verify and authenticate with a fast, seamless, friction-free user experience, making it simply for non-tech-savvy people to quickly take pictures of their ids and themselves. Because a bad UX means abandonment, it means lack of adoption, it means an unhappy interaction with the enterprise.

For some light reading about our amazing solutions, check out our library.

It’s the greatest level of assurance with the least friction, meaning the best identity authentication option available. To learn more about the fastest, most accurate, and most friendly biometric authentication solution on the market, give us a read. And please reach out to us at https://authid.ai. We’ll be happy to show you how your best avenue for a friendly, secure identity verification experience is literally staring you in the face.

How did we become the best biometric authentication platform on the market? How did authID rate so high in various biometric technology reviews? We started out by aiding third world countries in holding free and fair elections, where personal technology is not nearly as prevalent as in other parts of the world. We accomplished this by biometrically registering legitimate voters, then authenticating them at polling time to ensure that only those legit voters were the ones casting their ballots. Since then we have rolled out our solutions to financial services companies, workforce management companies, banks, healthcare, and other organizations who wish for only bona fide employees or consumers with legit biometric ids to access their most sensitive digital assets.

Verification on Day Zero, authentication on Day One and beyond. authID does this quickly, accurately, and with the smoothest, most friction-free user experience available. Users need that easy experience, while the host needs it to be right. Very recently a customer won a CSO award for their use of authID’s patented technology for verification and authentication.

authID verifies the validity of physical id documents (driver’s licenses, passports, state-issued id’s, etc.), supporting over 13,000 documents from over 200 countries and territories around the world, while employing dozens of security checks and markers to guarantee that validity. We then verify the user by their selfie, performing biometric liveness detection via NIST PAD Level 2. Ensure we have the right document, ensure we have a real person, then put them together to ensure we have the right individual.

authID’s browser-based interface (meaning no app to download) literally walks users through the capture process with virtual frames and digital guidance. And we process that data in under 700 milliseconds. Nothing friendlier, nothing faster.

Once that facial biometric is registered, you only need your face to authenticate, day after day, on your smartphone, desktop, or pad. If you lose or upgrade your device, that same face is all you need to instantly and seamlessly recover your access.

Footnotes

Authentication vs. authorization

What is authentication?

Wikipedia – Authentication

What is access control? | Authorization vs authentication

Verification vs Authentication – Do you know the difference?

What is the difference between Authentication and Verification?

What is the difference between verification, authentication and access management?

Do you know the differences between Identification, Verification and Authentication?