Authentication vs. Authorization – What is the Difference Exactly?
The distinction between authentication and authorization is many times missed or confused. Some of the confusion has to do with the fact that the short form for authentication and authorization is the same – “auth” – so a delegated authorization scheme like OAUTH can be easily confused with something that has to do with authentication. But authentication and authorization are really two simple and complementary concepts that work in tandem to protect access to resources.
Authentication is the process of proving that users are who they claim to be. In other words, proving that the user behind the keyboard is the actual owner of the user account associated with the username.
Authorization is the process of determining which resources an authenticated user is permitted to access and which operations the user is permitted to perform on the resource. For example, can a user access the HR folder on the company file server, which files in the folder can he access and can he read and write to it or maybe just read-only.
Based on the two definitions above, there is a natural order in which authentication and authorization are performed. Users are first authenticated to establish they in fact own the username account. Once their identity is known, their access permissions to resources – their authorizations – are looked up in the authorization system and enforced.
Authentication and authorization work in tandem to prevent unauthorized access to data and systems. In the most basic setup, users are authenticated once, typically when logging on to the company network, and their authorizations/access permissions are determined based on the role associated with their user account. For example, a user is authenticated when logging on to their Windows desktop, and their authorizations are determined by the group to which their user account is associated – e.g. system administrator, finance employees, developers, etc. In more modern setups, users are authenticated more frequently, and authorizations are defined at a more granular level. In some cases, authorizations are also contingent on various contextual parameters. For example, users are authenticated every time they request access to a resource, and authorization is granted for accessing and performing specific operations on a specific resource. Authorizations may be further limited by where is the user connecting from, what is the security posture of the device he is using, what has this user accessed historically, etc.
The concepts of authentication and authorization can be applied to human users and also to unattended software and systems interacting with one another without human intervention (e.g. one application asking for services from another software via an API interface).
So what are common ways to authenticate users?
- Passwords were the default way for authenticating users for ages. The user enters a username, which tells the system who the user is claiming to be, and the password is a shared secret that only the “real” user and the authenticating software should know. If the user is able to prove their identity by recalling the right password then the authentication service will assume that the user is who the username says he is.
- Two-factor authentication. As passwords became increasingly vulnerable to stealing and other attacks (primarily via phishing), additional authentication factors were piled on top of the standard username-password combination. These factors offer a stronger, higher-assurance form of authentication. The first factor typically remains the password, but in addition to the password, the user needs to prove possession of a physical authenticator (something the user has), or produce a biometric or behavioral print (something the user is). A common second-factor authenticator is proving possession of a registered hardware authentication token (i.e. OTP token or USB key) or device (i.e. mobile phone). Proof of possession is generally done using one-time password (OTP) technology or public-key cryptography (PKI certificates).
- Biometric authentication has seen a dramatic increase in use, whether as part of an MFA scheme or as a standalone authentication method. Many biometric signatures are in use today, the most popular being fingerprint and facial signatures. Biometric prints can be obtained from a fingerprint sensor embedded in most mobile devices and laptops, face image can be taken from the device camera, or voice print-captured by its microphone. Behavioral biometrics are also used to uniquely identify a user. Unique user behaviors can be detected by measuring the distinctive way in which the user strokes the keyboard (keystroke dynamics) or the unique patterns used to draw a signature.
- Passwordless authentication is likely the future form of authentication, as it is more secure than passwords and provides a better experience for users. As its name suggests, passwordless authentication removes passwords as a means of proving identity and replaces them with one or more (typically two) alternative forms of authentication. Most commonly used is a registered mobile device in combination with a fingerprint taken from the device’s sensor. Other forms of passwordless authentication can be a registered mobile device in combination with a faceprint or voiceprint, a dedicated USB authentication token device, etc.
Authorization schemes historically defined user permissions based on the assigned role of the user. But more modern authorization approaches implement a more granular approach that looks at what specific capability or data the user is trying to access, and contextual information associated with the access request – e.g. where is the user accessing from, what is the security posture of his device, is this atypical behavior for the user, etc.
Under a role-based permissions scheme, each user account is assigned a role definition, and permissions are automatically associated with the role. For example, a user with an admin role has extensive permissions to read and write to all resources, whereas a user with a contractor role may have read-only permissions to a small subset of applications and databases.
More granular permissions schemes have become more mainstream in recent years. Zero-trust, with its “never trust, always verify” approach, grants permissions in a very particular way. For example, a user may have access to the salaries folder owned by the HR department, but only to the salaries of his direct subordinates, and only when accessing from the company issued computer during work hours.
Passwordless authentication and Zero Trust Architectures are two strong trends in authentication and authorization that will likely continue to be a major investment area for companies in the coming years.
The adoption of passwordless authentication is driven by the realization that password vulnerabilities are at the heart of a great majority of security breaches. Passwords at the hands of users are easily compromised using various flavors of phishing attacks, or simply guessed by sophisticated attackers. Passwordless authentication offers a superior alternative to passwords. It offers better security, a better user experience, and is cheaper to own and operate.
Zero Trust acknowledges that authenticating users at the front gate – at the network perimeter – and authorizing them to roam free and access anything and everything after they’ve entered the perimeter no longer works. Instead, Zero Trust requires users to authenticate more frequently and authorizes them to access resources only on an as-needed basis. It is a much more granular authentication and authorization scheme that seeks to positively vet the identity of every user asking for access to a resource, and verify that that user has the minimum permissions required to perform his job.
Single Sign-On – How Does it Work and What is Passwordless SSO?
Single Sign-On – How Does it Work and What is Passwordless SSO?
Small business security: to MSSP or not to MSSP?