Authentication and authorization are two closely related processes. In authentication, a system verifies a person or entity is who they claim to be by checking against one or more authentication factors. From there, authorization dictates what level of access they have within the system. A marketing associate might have access to marketing documents, for instance, but not to the company’s personnel files.
In this article, we’ll discuss authentication and authorization, as well as how they fit together in a security system.
Through authentication, a system verifies a user is who they say they are. First, however, a user has to say who they are – this step is called identification. Once a user has identified themselves, the system proceeds to authenticate their identity.
For example, to enter a bar, Aaron identifies himself by showing his driver’s license to a bouncer. The bouncer then compares the ID photo against Aaron himself, and checks the date-of-birth to make sure Aaron is 21 or older. If everything checks out, the bouncer authorizes Aaron to enter the bar and start pounding White Claws – more on authorization in a moment.
Authentication can look very different in different contexts. To withdraw money from an ATM, you would present your debit card and then enter a PIN. To check your email, you might enter a username and password – or you might just unlock your iPhone via facial recognition and open your email app from there, no password required.
All of these examples rely on one or more authentication factors, which the system uses to verify your identity. There are three main types of authentication factors:
- Something you know factors, such as passwords and PINs, involve a secret tidbit of information. These factors are common to the logical access controls that govern computer systems.
- Something you have factors, such as keys or ID badges, involve something tangible you carry with you. These factors abound when it comes to physical security – especially the lock and key, which is probably the most pervasive access control method in existence.
- Something you are factors, also known as biometrics, include fingerprint scanners, facial recognition, and any other authentication that relies on your body itself.
In our first example, the bouncer relies on something you have (a driver’s license) as well as something you are (facial recognition of Aaron himself). That makes this an instance of multi-factor authentication, in which more than one factor is used to authenticate someone.
The ATM example would also qualify, relying on something you have (a debit card) as well as something you know (a PIN).
In contrast, single-factor authentication relies on only one factor, such as a password. Multi-factor authentication is significantly stronger – it’s much easier for an attacker to crack a password alone than to break into an account that also requires a one-time code sent to that person’s phone.
Once a user has been authenticated, authorization determines what objects they have access to, as well as what level of access they have to those objects.
Greg might have access to files pertaining to cruises and to theme parks, but that doesn’t mean he can do whatever he wants in those domains. He might be able to read and modify files under cruises, for instance, but not delete them; when it comes to theme parks, he might be able to see the file names, but nothing more.
On most computer systems, authorization is granted based on access control lists. These lists consist of subjects and objects, detailing what kinds of access different subjects have to a given object. Under Windows, every file or folder has an access control list that determines how users and groups can access it.
A subject doesn’t always have to be a person. An application or network can also be a subject – if you enable a program to read and write files on your computer, for instance, it then becomes a subject.
Discretionary access control, or DAC, is the most common of these models. Under discretionary access control, the owner of an object may hand out access at their discretion. If Tom is the owner of the “cruises” domain, he can then give Greg access to read or write files in that domain – or even grant him administrative privileges, allowing Greg to dole out access at will.
Mandatory access control, in contrast, is much more top-down. Under mandatory access control, or MAC, access cannot be freely given. Instead is handed down on a need-to-know basis: if you don’t need access to do your job, you don’t get access. These aren’t the only models, and you can read about more in our complete guide to access control models.
Many systems use a combination of different models. For the most part, Windows operates on the discretionary access control model. The core of the operating system itself, however, is protected under a mandatory access control model. This makes it much less likely users will unknowingly grant broad control over their computer to malicious software.
How Authentication and Authorization Fit Together
Authentication and authorization are two intertwined processes. Authorization relies on authentication to function; if you cannot accurately determine who your users are, you cannot effectively grant or deny them access within a system.
You don’t strictly need authorization in place for authentication to function. But they typically go hand-in-hand: usually, authentication is immediately followed by authorization, as the verified user is granted access to the system in question.
The AAA Framework
The AAA framework is a popular standard for governing access across systems. AAA, in this case, stands for authentication, authorization, and accounting.
Accounting entails monitoring and logging user activity on the system. With accounting in place, all user actions are logged and can be referred back to should an issue arise. Like authorization, accounting relies on authentication to function. You can hardly log user activity if you don’t know who your users are.
The AAA framework is the basis for several security protocols, such as RADIUS and TACACS+. Any protocol that covers authentication, authorization, and accounting counts as a AAA protocol, though under some AAA protocols, administrators can choose not to implement all three processes.