LFCA 94 🐧 Authentication vs Authorization
Authentication and authorization are two different things. They are often confused because they work together, and because both are abbreviated as “auth.” But they answer different questions. Authentication answers “Who are you?” Authorization answers “What are you allowed to do?” . The LFCA exam places this topic under Security Fundamentals, which carries 14% of the total weight. The competency list includes “Security” and “Sensitive Data.” Understanding the distinction is the foundation for every access control decision in a Linux system.
Key point: Authentication happens first. Authorization happens second. You cannot authorize a user you have not authenticated. The authentication process proves identity. The authorization process decides permission. A user can be authenticated but not authorized. A user cannot be authorized without being authenticated. This ordering is the A1-A2 ordinality that the W3C describes: authentication is A1, authorization is A2, and A1 must come before A2 .
Why the distinction matters
The two concepts are different, and conflating them leads to security problems. A system that authenticates users but does not authorize them gives every authenticated user access to everything. A system that authorizes users but does not authenticate them gives access to anyone who can claim an identity.
The identity problem. Authentication establishes who the user is. It challenges the user for credentials: a password, a fingerprint, a certificate, a one-time code . The credential proves that the user is who they claim to be. The result of authentication is an identity: a verified claim about the user.
The permission problem. Authorization decides what the authenticated user can do. It checks the user’s identity against a policy: a list of permissions, a set of roles, a set of attributes . The result of authorization is a decision: allow or deny.
The audit problem. Authentication and authorization produce different logs. The authentication log records who logged in, when, and from where. The authorization log records what the user tried to do and whether the attempt was allowed. Separating the two makes the audit trail clearer .
The principle of least privilege. Authorization enforces the principle of least privilege: users should have only the permissions they need to perform their job functions, and no more . Authentication does not enforce least privilege. It only verifies identity.
The trade-off. Authentication and authorization are separate concerns, but they are implemented together. A web application authenticates the user with a username and password, then authorizes each request based on the user’s role. The two are coupled in the implementation but distinct in the concept. The LFCA exam tests the distinction, not the implementation.
a. Authentication (AuthN)
Authentication is the process of proving identity. It challenges a person, a machine, or a software component for credentials and verifies that the credentials are valid . The word is sometimes shortened to AuthN.
The three factors of authentication are:
Something you know. A password, a PIN, a passphrase. The user proves identity by providing a secret that only they should know. This is the most common factor, and the weakest on its own because passwords can be guessed, phished, or leaked .
Something you have. A hardware token, a smartphone, a smart card. The user proves identity by possessing a physical object. This is stronger than a password because the attacker must physically obtain the object .
Something you are. A fingerprint, a facial scan, a retinal scan. The user proves identity by presenting a biometric characteristic. This is the strongest factor because the characteristic is unique to the user and difficult to forge .
Multi-factor authentication (MFA) combines two or more factors. A password plus a one-time code from a smartphone is two factors: something you know and something you have. MFA is significantly stronger than any single factor because an attacker must compromise multiple independent credentials .
In Linux, authentication is handled by PAM (Pluggable Authentication Modules). The pam_authenticate module challenges the user for credentials. The pam_unix module validates a password against /etc/shadow. The pam_google_authenticator module adds a TOTP second factor. PAM is the framework that makes authentication modular and configurable per service .
b. Authorization (AuthZ)
Authorization is the process of deciding whether an authenticated user is allowed to access a resource. It validates that the user, machine, or software component is granted access to certain resources . The word is sometimes shortened to AuthZ.
The authorization decision is based on a policy. The policy can be:
Role-Based Access Control (RBAC). Permissions are assigned to roles, and users are assigned to roles. A user with the admin role has the permissions of the admin role. A user with the user role has the permissions of the user role . RBAC is simple and works well when roles are stable and the number of roles is small.
Attribute-Based Access Control (ABAC). Permissions are based on attributes of the user, the resource, and the environment. A policy might say: “Allow access if the user’s department is finance and the resource is a financial report and the time is during business hours.” ABAC is more expressive than RBAC but more complex to manage .
In Linux, authorization is handled by file permissions and access control lists (ACLs). A file has an owner and a group. The permission bits determine whether the owner, the group, or others can read, write, or execute the file. The chmod command changes the permission bits. The chown command changes the owner. The setfacl command sets ACLs for more granular control .
The principle of least privilege is the guiding principle for authorization. A process should run with the minimum permissions needed to complete its task, and no more. A web server should not run as root. A database user should not have DROP TABLE permission if the application only needs SELECT and INSERT .
c. The Relationship in Practice
Authentication and authorization work together in a sequence.
Step 1: Identification. The user provides an identifier: a username, an email address, an account number. The identifier is a claim about who the user is. Identification is not authentication. It is the first step .
Step 2: Authentication. The system challenges the user for credentials. The user provides a password, a token, a biometric. The system verifies the credentials. If the credentials are valid, the user is authenticated. The identity claim is now verified .
Step 3: Authorization. The system checks the authenticated identity against the policy. The policy determines what the user is allowed to do. If the policy allows the action, the request is granted. If the policy denies the action, the request is rejected .
Step 4: Audit. The system logs the authentication and the authorization decisions. The log records who the user is, what they tried to do, and whether the attempt succeeded or failed. The log is the audit trail .
In a Linux login, the sequence is: the user provides a username (identification), the system challenges for a password (authentication), the system checks the user’s shell and permissions (authorization), and the login is recorded in /var/log/auth.log (audit). The same sequence applies to sudo: the user is authenticated, then authorized to run the command as root.
Complete Example Session
This session demonstrates authentication and authorization in a Linux system.
# ============================================
# PART 1: IDENTIFICATION
# ============================================
# The user provides a username at the login prompt.
# The username is a claim about identity.
# It is not yet authenticated.
# login: alice
# ============================================
# PART 2: AUTHENTICATION
# ============================================
# The system challenges for a password.
# The password is the credential.
# The system verifies the password against /etc/shadow.
# Password: ********
# If the password is correct, the user is authenticated.
# If the password is incorrect, the authentication fails.
# ============================================
# PART 3: AUTHORIZATION
# ============================================
# After authentication, the system checks the user's permissions.
# The user's shell is set in /etc/passwd.
# The user's groups are set in /etc/group.
# The file permissions determine what the user can access.
ls -l /etc/shadow
# Output:
# -rw-r----- 1 root shadow 1234 Oct 1 12:00 /etc/shadow
# Alice can read the file if she is in the shadow group.
# She cannot read the file if she is not in the shadow group.
# The authorization decision is based on the file permissions.
# ============================================
# PART 4: THE PRINCIPLE OF LEAST PRIVILEGE
# ============================================
# The web server runs as the www-data user.
# The www-data user has minimal permissions.
# It can read the web files but cannot modify the system.
ps aux | grep nginx
# Output:
# www-data 1234 ... nginx: worker process
# The web server does not run as root.
# The authorization policy limits the damage if the server is compromised.
# ============================================
# PART 5: SUDO — AUTHENTICATION AND AUTHORIZATION
# ============================================
# sudo requires authentication (the user's password).
# sudo requires authorization (the user must be in the sudoers file).
sudo cat /etc/shadow
# The system authenticates Alice with her password.
# The system authorizes Alice if she is in the sudo group.
# The command runs as root if both checks pass.
# ============================================
# PART 6: THE AUTH LOG
# ============================================
# The authentication and authorization decisions are logged.
sudo tail /var/log/auth.log
# Output:
# Oct 1 12:00:00 host login: pam_unix(login:session): session opened for user alice
# Oct 1 12:00:05 host sudo: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/bin/cat /etc/shadow
# The log records who authenticated and what they were authorized to do.
# ============================================
# PART 7: ROLE-BASED ACCESS CONTROL
# ============================================
# A user is assigned to a role.
# The role has permissions.
# The user inherits the permissions of the role.
groups alice
# Output:
# alice : alice sudo developers
# Alice is in the alice, sudo, and developers groups.
# The sudo group has the permission to run commands as root.
# The developers group has the permission to access the development files.
# ============================================
# PART 8: FILE PERMISSIONS
# ============================================
# The file permissions determine who can read, write, and execute.
ls -l /home/alice/project.txt
# Output:
# -rw-r--r-- 1 alice developers 1234 Oct 1 12:00 /home/alice/project.txt
# The owner (alice) can read and write.
# The group (developers) can read.
# Others can read.
# ============================================
# PART 9: ACCESS CONTROL LISTS
# ============================================
# ACLs provide more granular control.
setfacl -m u:bob:rw /home/alice/project.txt
# Bob is granted read and write access to the file.
# The ACL overrides the default group permissions.
getfacl /home/alice/project.txt
# Output:
# user::rw-
# user:bob:rw-
# group::r--
# other::r--
# ============================================
# PART 10: THE SUMMARY
# ============================================
# Authentication: who are you?
# - Password, token, biometric
# - Handled by PAM
# - Produces an identity
# Authorization: what are you allowed to do?
# - File permissions, ACLs, roles
# - Handled by the kernel and PAM
# - Produces an allow or deny decision
# Authentication comes first.
# Authorization comes second.
# The audit log records both.The ten parts cover identification, authentication, authorization, the principle of least privilege, sudo, the auth log, role-based access control, file permissions, access control lists, and the summary.
Quick Reference
The Distinction
| Aspect | Authentication | Authorization |
|---|---|---|
| Question | Who are you? | What are you allowed to do? |
| Order | First | Second |
| Abbreviation | AuthN | AuthZ |
| Result | Identity | Allow or deny |
| Linux tool | PAM | File permissions, ACLs |
The Three Factors
| Factor | Example |
|---|---|
| Something you know | Password, PIN |
| Something you have | Token, smartphone |
| Something you are | Fingerprint, face |
The Authorization Models
| Model | Basis |
|---|---|
| RBAC | Roles |
| ABAC | Attributes |
| DAC | File permissions |
The Linux Commands
| Command | Purpose |
|---|---|
login | Authenticate a user |
sudo | Authenticate and authorize |
chmod | Change permissions |
chown | Change owner |
setfacl | Set ACLs |
groups | Show group membership |
Best Practices
✅ Do This:
# Use MFA for sensitive accounts
# Something you know + something you have # ✅# Follow the principle of least privilege
# Grant only the permissions needed # ✅# Use roles for authorization
# Assign users to roles, not individual permissions # ✅# Log authentication and authorization decisions
# The audit trail is the record # ✅❌ Don’t Do This:
# Don't run services as root
# Use a dedicated low-privilege user # ❌# Don't use passwords alone for sensitive access
# Add a second factor # ❌# Don't confuse identification with authentication
# A username is a claim, not proof # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Authenticated but not authorized | User logged in but lacks permission | Check group membership |
| Authorization without authentication | No identity check | Add authentication |
| Over-privileged service | Runs as root | Use a dedicated user |
| No audit log | Not configured | Enable auth.log |
Real-World Examples
1. Identification
login: alice2. Authentication
Password: ********3. Authorization
ls -l /etc/shadow4. MFA
# Password + TOTP code5. RBAC
groups alice6. File Permissions
chmod 640 file.txt7. ACL
setfacl -m u:bob:rw file.txt8. Sudo
sudo command9. Auth Log
tail /var/log/auth.log10. Least Privilege
# Web server runs as www-dataVisual
Authentication vs Authorization
┌──────────────────────────────────────────────┐
│ AUTHENTICATION (AuthN) │
│ "Who are you?" │
│ ├─ Password │
│ ├─ Token │
│ └─ Biometric │
│ │ │
│ ▼ │
│ IDENTITY │
│ │
│ AUTHORIZATION (AuthZ) │
│ "What are you allowed to do?" │
│ ├─ Permissions │
│ ├─ Roles │
│ └─ ACLs │
│ │ │
│ ▼ │
│ ALLOW or DENY │
│ │
│ Authentication first. Authorization second. │
│ │
└──────────────────────────────────────────────┘The Sequence
┌──────────────────────────────────────────────┐
│ 1. IDENTIFICATION │
│ └─ Username │
│ │
│ 2. AUTHENTICATION │
│ └─ Password, token, biometric │
│ │
│ 3. AUTHORIZATION │
│ └─ Policy check │
│ │
│ 4. AUDIT │
│ └─ Log the decision │
│ │
└──────────────────────────────────────────────┘The Linux Stack
┌──────────────────────────────────────────────┐
│ USER │
│ └─ Username, password │
│ │
│ PAM │
│ └─ Authentication modules │
│ │
│ KERNEL │
│ └─ File permissions, ACLs │
│ │
│ AUTH LOG │
│ └─ /var/log/auth.log │
│ │
└──────────────────────────────────────────────┘The Principle of Least Privilege
┌──────────────────────────────────────────────┐
│ PRINCIPLE OF LEAST PRIVILEGE │
│ │
│ User: alice │
│ ├─ Needs: read project files │
│ ├─ Has: read project files │
│ └─ Does not have: write system files │
│ │
│ Service: nginx │
│ ├─ Needs: read web files │
│ ├─ Has: read web files │
│ └─ Does not have: root access │
│ │
│ Grant only what is needed. │
│ │
└──────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Authentication | Proves identity |
| Authorization | Decides permission |
| Abbreviation | AuthN vs AuthZ |
| Order | AuthN first, AuthZ second |
| Factors | Know, have, are |
| MFA | Two or more factors |
| RBAC | Role-based access control |
| ABAC | Attribute-based access control |
| Linux authentication | PAM |
| Linux authorization | File permissions, ACLs |
| Principle | Least privilege |
| LFCA weight | Security Fundamentals, 14% |
Key takeaways:
- Authentication proves identity; authorization decides permission. Authentication answers “Who are you?” Authorization answers “What are you allowed to do?” They are separate processes with separate purposes .
- Authentication comes before authorization. You cannot authorize a user you have not authenticated. The W3C calls this the A1-A2 ordinality: authentication is A1, authorization is A2 .
- The three factors of authentication are something you know, something you have, and something you are. Multi-factor authentication combines two or more factors. It is significantly stronger than any single factor .
- Authorization is based on a policy. The policy can be role-based (RBAC), attribute-based (ABAC), or discretionary (DAC). The principle of least privilege guides the policy: grant only the permissions needed .
- In Linux, authentication is handled by PAM. The
pam_authenticatemodule challenges for credentials. Thepam_unixmodule validates passwords. PAM is modular and configurable per service . - In Linux, authorization is handled by file permissions and ACLs. The permission bits determine who can read, write, and execute. ACLs provide more granular control. The kernel enforces the policy .
- The audit log records both authentication and authorization decisions. The
/var/log/auth.logfile records who logged in, what they tried to do, and whether the attempt was allowed. The log is the audit trail .
Remember: Authentication is the gatekeeper. It verifies identity. Authorization is the guard. It checks permission. Authentication comes first. Authorization comes second. A user can be authenticated but not authorized. A user cannot be authorized without being authenticated. The three factors are know, have, and are. MFA combines them. RBAC and ABAC are the models. PAM handles authentication in Linux. File permissions and ACLs handle authorization. The principle of least privilege guides the policy. The audit log records the decisions.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!