Demystifying authentication and authorization
When you hear the term Auth, what comes to mind? You probably think of signing into a system with your username and password, and you’re half right. But auth is bigger than that. The bucket term also includes everything you can do in a system once you submit those credentials. Auth is really shorthand for two independent but closely related components that cover different aspects of system access: authorization and authentication. Depending on context, auth can refer to either one or both.
Understanding the difference between authentication and authorization is really important for securing resources. Just because an identity can be verified doesn’t mean that identity should be able to access a resource. Similarly, just because an identity says they should be able to access a resource does not guarantee the identity isn’t fraudulent. The two concepts must be used in tandem to validate resource access.
Authentication
The first player in the auth space is authentication, often written as AuthN. Authentication is responsible for handling identity verification, ensuring someone is who they say they are. Services can authenticate a user through many different techniques. Common authentication methods include username and password credentials, certificate exchanges, and biometrics.
Username and Password
Username and password authentication is one of the most widely used methods for verifying an identity. In this method, the authenticating service prompts the user for a username and password combination. The service compares the password provided by the user against a password stored in a database. If the values match, the authenticating server deems the identity verified.
The password stored in the database is usually not the user’s actual password. Storing a password in “plain-text” is a huge liability because if the database is compromised in a hack, the password is also compromised. Commonly, the value stored is run through a one-way hashing algorithm to generate a garbled version of the password that is very difficult to decipher. When the user tries to sign in, the password provided is also run through the same hashing algorithm. The service then compares the garbled versions to determine a match.
Certificate Exchange
Another common form of authentication is a certificate exchange. This is often used for verifying the identity of devices in a system rather than individuals. In this exchange, an independent certifying authority presents the user or device with a certificate and a set of encryption keys. One of these keys is available to the public (aptly known as the “public key”), while the other remains with the user or device (the “private key”). When the user or device attempts to authenticate, they hand the authenticating server the certificate as well as their public key. The authenticating server ensures that the certificate is valid and the public key is correctly associated with the certificate. The service then asks the user to encrypt a random value using their private key. If the authenticating server can properly decrypt the value, the user’s identity is considered verified.
Biometrics
Biometric authentication is becoming increasingly popular because it is so difficult to fake. In this method, a user’s physical attributes are used to verify identity. Biometric methods include fingerprint scanning like Apple’s Touch ID, facial recognition like Apple’s Face ID or Windows Hello, and voice recognition.
Authorization
Authentication’s complement is authorization, often written as AuthZ. Authorization isn’t about verifying who you are. Instead, authorization is concerned with what you have access to. Authorization trusts that your identity has been verified and shifts focus to granting or revoking access to protected resources. Authorization typically relies on some form of ticket or token that describes a user and their roles, and consequently what they can or cannot access. Access rights are determined by access control rules, often configured using role based access control (RBAC) or policy based access control (PBAC) rules.
Role Based Access Control
Role based access control uses an individual’s role to determine their access level. Their role is often associated with their day to day responsibilities and may be determined by job title or department. This approach to authorization simplifies access control by granting or denying access to entire roles rather than managing individual permissions.
Policy Based Access Control
Policy based access control focuses on developing fine-grained permissions for resources. Instead of determining broad access based solely on role, policy based approaches outline specific criteria required to access individual pieces of information. While it requires more work to configure, policy based access control offers a higher degree of control over resources.
| Authentication (AuthN) | Authorization (AuthZ) |
| Focuses on verifying a user’s identity | Focuses on verifying someone’s permissions |
| Typically includes some credential exchange – username and password – certificate exchanges – biometrics | Typically includes some access control rules – Policy based access control (PBAC) – Role based access control (RBAC) |
| Grants the user a short-lived token | Uses a token to determine a user’s rights |
| Controllable by the user | Controllable by the administrator |
A Real World Scenario
To help illustrate the differences between authentication and authorization, let’s imagine a scenario. You’ve been invited to an exclusive, invitation only conference for Clever educators. Congratulations, it’s a tremendous honor! When you arrive at the venue, you’re greeted at the door by our friendly concierge. They ask to see your invitation and photo ID. Once they verify your identity, they hand you a lanyard. There are different lanyards for roles- principals and administration get one while teachers get another.
The expo hall is dappled with different technology partners. App partners, service providers and consultants are all represented in the sea of booths. You notice areas toward the back of the hall that are cordoned off, with event staff permitting or denying access by role. Some sessions are only for principals, while others are strictly for teachers. You head toward the session for your role, and event staff happily let you enter. When you try to sneak into a session for another role, our event staff reluctantly turn you away.
In this scenario, our concierge manages authentication. They checked your ticket and validated your identity. Once verified, they gave you a short-lived credential that granted you access to conference resources. Event staff checking lanyards handle authorization. They trust your lanyard is legitimate and your identity has been properly vetted. They instead focus on ensuring that attendees have a lanyard that matches the role required to participate in the session.
Authentication and authorization are two closely related elements of secure access control, but they have some vital differences. Authentication is focused on users’ identity, while authorization is interested in the permissions granted to those users. It is important for organizations to understand the concepts and implement both effectively to ensure the security of their systems and the confidentiality of their data. Clever takes this so seriously that we have a dedicated engineering team that is focused on controlling access to our districts’ sensitive data. Clever’s Auth team handles tens of millions of authentications and authorizations each and every day. The actual mechanics of authentication and authorization vary from protocol to protocol and are a bit beyond the scope of this article. Don’t worry though, Clever’s Auth team will dig into some of these protocols in future installments of this series!