How Do Authentication and Authorization Differ?

Authentication and authorization sound similar. They’re often mentioned together, they’re often both implemented with tokens, and the terms are sometimes used almost interchangeably — or as a portmanteau that suggests they’re the same thing.

Frequently, you’ll just hear the term “auth” and have to work out which of the two is meant: “modern auth” refers to authentication, but OAuth 2 is an authorization standard. And OpenID Connect, which extends Oauth, adds authentication as a layer on top of authorization.

They’re always related, but authentication and authorization are two different concepts that need to be separate steps in an access policy and may well be managed by different teams using different tools.

Authentication is verifying that a user is who they say they are: authorization is giving them permission to access a resource or perform a specific function.

The principles will seem familiar, suggested Alex Weinert, director of identity security at Microsoft. “If you’re walking into my store as a customer, you show your ID to say you’re 21 and you can buy alcohol. If you’re the manager, you can get into the back stockroom. If you come to the Azure portal and your claim says you’re an average user, you’re not going to be able to do very much, but if you come to the Azure portal and your claim says you’re a global administrator, you can do quite a lot.”

Typically authorization happens right after authentication, said Mike Hanley, GitHub’s chief security officer: “You are authorizing a user who you presumably figured out that they are who they say they are, via an authentication process.”

What you are allowed to do is based on who you are, but different systems and (usually) different teams handle the two steps of authentication and authorization. Authentication is the provenance of the identity provider, verifying those credentials using passwords, biometrics, one-time PINs, hardware keys or authentication applications, so the system knows it’s talking to the same person the identity was issued to — and then associating data, like their name and role, to them.

Authorization is something the security or application administrator handles and it’s based on what permissions are available for the system being accessed (either directly or mapped to the roles and attributes in the identity system used for authentication).

The user getting authenticated might be a machine rather than a human, using secrets and other credentials (usually X509 certificates that need to be provisioned securely) rather than a username, password or token, with the authenticated machine or workload being authorized to talk to another machine, or read and write data in the test but not the production environment.

Just as you don’t want users writing passwords down on sticky notes they keep on their keyboard, policies, secret scanning and credential rotation are important to avoid mistakes like checking credentials into repos, where they can be found and abused.

Stepping Up Authentication

As a user, you can usually see authentication happening (although it might be persistent, like staying logged into a website even if you close the browser tab) and you can often do things like changing your password or choosing which second factor you want to use. Users can’t change their authorization options and won’t see authorization happening.

But you might see another authentication request if you try to do something that’s considered important enough that your identity has to be verified again before you are authorized to do it. Some banks will let you log in to your account and make payments you’ve done previously with your username and password, but ask you to use 2FA to set up a new payee.

Conversely, authentication systems that use conditional access policies can recognize that you’re using the same device, IP address, location and network connection to access the same file share you access from that device, location and network every day to improve your productivity and not make you go through an authentication challenge.

“We have enough data about users who we’ve authenticated, the devices that they’re coming from, the workloads or applications that they’re trying to access, the network that they’re joining from that we can have systems reason about, ‘We’re pretty sure this is still you, so we’re going to allow this to happen without an additional step-up,’” Hanley said.

“You may not care if somebody accesses the payroll system from home to get their pay stub on their Windows 95 PC, but you’re definitely going to care if somebody is accessing the corporate finance system from anything other than likely a corporate-managed, fully patched and up-to-date machine that you own and operate.”

— Mike Hanley, chief security officer, GitHub

These are decisions about risk tolerance, he said: “We might say this application is so high risk or so high value that this workflow merits the friction, and I’ll dial up the friction only on this workflow to make sure that nothing bad ever happens.”

Authentication and authorization remain separate steps but with the increasing use of conditional access and Zero Trust approaches to identity, they are often entwined.

“One of the things that can play into an authorization decision is how strong your confidence is in the authentication,” Hanley said. “If you’re only username and password-authenticated, I might allow you to get to the lowest risk tier of applications, but I might step you up with a multifactor challenge or require you to [use] multifactor for any sort of medium-tier sensitivity. And then if you’re doing anything in the highest tier of sensitivity, I’m going to be constantly introducing friction to be sure that it is still you.”

That might include refusing authorization even when the authentication succeeds but reveals things about the connection that you’re uncomfortable with, Hanley ­noted. “I’ve authenticated Mike and Mike used his two-factor authentication, so I’m really sure that it’s Mike, but it’s coming from a network that I don’t recognize and a PC that I don’t trust because it’s not running the latest security updates, so the authorization decision changes.

“You may not care if somebody accesses the payroll system from home to get their pay stub on their Windows 95 PC, but you’re definitely going to care if somebody is accessing the corporate finance system from anything other than likely a corporate-managed, fully patched and up-to-date machine that you own and operate.”

Setting Higher Guardrails

Admins have the option of setting much richer policies to access high-value systems, whether that’s company finance or an important code repo. GitHub now insists you use tokens rather than passwords when authenticating Git operations, and those tokens can be set for very specific access. That’s similar to the Just Enough Admin authorization option for systems managed by PowerShell, where you can restrict what commands are allowed and even set a specific time period.

As Hanley explained, “Rather than sending somebody off with a bazooka when they don’t need it, you can give them a butter knife, and say come back to us when you actually need the bazooka and we’ll give it to you for a specific reason and a specific amount of time.”

Think of these approaches as guardrails, he suggested. “This instills a sense of operational safety and security because you’re less likely to make a human error that results in a bad situation from exercise of that excessive privilege. But it also protects you from the case that, even if you’ve strongly authenticated some user, it is still possible that their account could have been hijacked or somebody stole their session or somebody’s wrenched the laptop out of their hand.”

Continuous access evaluation catches cases like a user who is authenticated and authorized to use a particular application because they work in the finance division but then moves to another group or even leaves the company and still has access as long as their session token is valid. You want to revoke access immediately and again, Weinert pointed out, that needs coordination between authentication and authorization.

You may also need to consider (and monitor) application behavior, although app governance is also separate from authentication and authorization. Does an application have too many permissions that allow access to too much information that it doesn’t need and can be abused by attackers?

A ‘Blunt Force Tool’

Application roles and permissions are why authorization is a hard problem that sometimes gets punted over to the authentication system. Security teams don’t know the details of every application in every department or have the nuances of what different roles need to be entitled to do.

As Weinert asked, “Can you as an admin really manage the intersection of all possible roles of all possible apps in your environment?”

Particularly if you’re using Single Sign-On to federate access to older systems that don’t have modern authentication built-in, those systems you’re being authorized to use may have user and admin roles, or even very specific roles like “wire transfer administrator” or “shelf stocker” versus “checkout specialist.”

But they often don’t have a granular approach to permissions either, Weinert noted. In many systems, he said, authentication is essentially the authorization for certain roles. The rule is that if you’re allowed to be introduced to something, you will be allowed to use it: “If you even got here, I’m going to assume that you have some business being here.”

Weinert suggests thinking of the different things you’re authorized to do — anything from accessing a database to sending an email or configuring a virtual machine — as verbs. “Everybody has different verbs and different roles and different ways of exposing those, so authentication becomes the blunt force tool that admins use to regulate over the top,” he said.

“In the world of authentication, if I don’t generate an access token for you, I’m performing a form of authorization.”

—Alex Weinert, director of identity security, Microsoft

The developer may not have planned it that way, but if an application deals with financial data, a security admin might decide to only allow authorization if authentication shows the user’s device meets the most stringent access policy. “In the world of authentication, if I don’t generate an access token for you, I’m performing a form of authorization,” Weinert said.

Reducing the complexity of this will require coming up with some common tasks that apps authorize users for, like reading and writing sensitive data, which Weinart suggests could work alongside a provisioning standard like SCIM, the System for Cross-Domain Identity Management that handles common attributes like names.

“You’ll see more of a shift from this coarse-grained access control that happens in the authentication step to a finer-grained authorization that can happen as we normalize some of that experience,” Weinert said.

OAuth (and OpenID Connect) and complicated and better authorization tools are only slowly emerging.

MSAL, Microsoft’s multiplatform authentication library, avoids the need to work directly with OAuth for authorization, as well as extending extends OpenID Connect with options like conditional access.

Google’s Zanzibar API (open sourced as Keto and the open source Oso library (which handles rules written in the Polar policy language) take a different approach, aiming to help decouple authorization from authentication and make it easier to build exactly the authorization you need.

The Advantages of Authentication Services

The authentication side is much better served, which is helping the move away from passwords. Historically, checking the user is who they say they are has been a single step: if I have the username and password, I must be the user.

But those days are drawing to a close.

“With phishing and credential stuffing and all the various attacks that feed into taking over accounts, that’s generally insufficient,” Hanley warned. “Passwords have all these deficiencies; they tend to be things that people write down, they tend to be things that people reuse. We give people complex password rules, which makes it difficult for them to adopt them as a primary factor, and that means they end up spilling or being abused or found in other places when they shouldn’t be.”

The FIDO2 and WebAuthn standards make it easier to move to multi-factor authentication that uses biometrics, authentication apps or hardware tokens because they’re built into common operating systems and browsers. Biometrics like Windows Hello cameras and Touch ID on Apple devices make this far more convenient for users when apps and websites use those for strong authentication.

There are some situations, like air-gapped networks, where you will have to create your own identity and authentication system. But when you can, picking one of the cloud identity provider services  (like Auth0, Azure AD B2B and B2C, Google Workspace, Okta, Twilio’s Authy and others), gives you a wider choice of authentication methods, as well as their expertise in the systems that underlie even something as common as SMS 2FA.

“We know supply chain security is under attack today, and there are a variety of interesting and exotic attacks out there. We need to protect the developers and the communities that are doing that work.”

—Mike Hanley, chief security officer, GitHub

“You have to manage this complex relationship with telcos,” said Catie Kolander, senior product marketing manager with Twilio’s account security business unit. “You may have to manage a pool of numbers to be able to send the one-time passcodes. Do you have access to a backup route in the event that delivery fails?

“You’re going to start seeing an increase in support costs when they say ‘I didn’t get my authentication code,’ and they send that message seven times.”

For internal users, organizations can mandate authentication methods; if you’re dealing with customers you may have to be more flexible, bearing in mind who will be authenticated, on what device and what they’re comfortable with, Kolander pointed out. ”If you only offer something like SMS, are you excluding a large user base that doesn’t have a mobile phone? Do you need to have something like a voice call or email?”

That’s not the most secure option for authentication, but it may be necessary for some audiences. For others, you may need over-the-top methods like WhatsApp, voice calls, Time-Based One-Time Passcodes (commonly known as TOTP) through authenticator apps, or push authentication inside your mobile app — which takes more development work but is the only option that lets users explicitly deny access.

Identity services also simplify getting extra information about the connection beyond just the IP and device information to use in authentication decisions. As Kolander told us, “If it’s a phone number that’s coming from a country that you shouldn’t be seeing be a connection from, you have the ability to block that or provide extra layers of authentication.”

These levels of checks and challenges do mean more work for admins and users, but it’s important, especially for developers. “We are more than intentionally not just nudging but really pushing toward what we think good looks like,” Hanley said.

“We know supply chain security is under attack today, and there are a variety of interesting and exotic attacks out there. We need to protect the developers and the communities that are doing that work.

“We have to be a secure platform, but part of it is also pushing that account security out to the edge so that we can enable them to have better control over these user accounts, which are authorized to and part of some of the biggest and most important, open source projects that power all of the devices we use and software we interact with each and every day.”