Authentication and Authorization

Authentication and authorization are the twin pillars of access control in software systems. Authentication answers "Who are you?" while authorization answers "What are you allowed to do?" Though often confused or conflated, they are distinct concerns requiring different mechanisms. A system that authenticates perfectly (correctly identifying every user) but authorizes poorly (giving everyone admin access) is just as insecure as one that fails to authenticate at all. Understanding both concepts deeply is essential for building systems that protect sensitive data while providing appropriate access to legitimate users.

Authentication: Verifying Identity

Authentication is the process of verifying that a user or system is who they claim to be. It typically relies on one or more factors:

Something You Know: Passwords, PINs, security questions. This is the weakest factor alone because knowledge can be stolen, guessed, or shared.

Something You Have: Physical tokens, mobile phones (for SMS codes), hardware security keys (YubiKey), or authenticator apps. These are stronger because they require physical possession.

Something You Are: Biometrics—fingerprints, facial recognition, iris scans, voice patterns. These are convenient but raise privacy concerns and cannot be changed if compromised.

Multi-Factor Authentication (MFA) combines two or more factors, dramatically increasing security. Even if an attacker steals a password (something you know), they cannot authenticate without also possessing the user's phone (something you have).

Authentication Mechanisms

Password-Based Authentication remains the most common approach despite its weaknesses:

Token-Based Authentication (JWT) issues a signed token after initial authentication. The token contains claims about the user's identity and permissions, eliminating the need to query the database on every request:

OAuth 2.0 enables third-party applications to access user resources without sharing credentials. When you "Sign in with Google," the application receives an access token from Google rather than your password. The OAuth flow involves:

1. Application redirects user to authorization server (Google)
2. User authenticates with the authorization server
3. Authorization server issues an authorization code to the application
4. Application exchanges the code for access and refresh tokens
5. Application uses the access token to call APIs on the user's behalf

Single Sign-On (SSO) allows users to authenticate once and access multiple applications. Enterprise SSO systems (like Okta, Azure AD) provide centralized authentication, simplifying user experience while enabling centralized security policy enforcement.

Authorization: Controlling Access

Once identity is established, authorization determines what actions the authenticated user can perform:

Role-Based Access Control (RBAC) assigns permissions to roles, then assigns roles to users. This simplifies administration—instead of managing permissions for 10,000 individual users, you manage a handful of roles:

Attribute-Based Access Control (ABAC) makes access decisions based on attributes of the user, resource, action, and environment. Rules like "Allow access if user.department == resource.department AND user.clearance >= resource.classification AND current_time is within business_hours" enable fine-grained, context-aware authorization.

Permission-Based Access Control assigns specific permissions directly to users or groups. More granular than RBAC but more complex to manage at scale.

Real-World Example: Healthcare System Access Control

A hospital information system demonstrates both concepts working together:

Authentication: Doctors authenticate using badge (something they have) + PIN (something they know). Nurses use fingerprint (something they are) + password. External consultants use username + password + one-time code from authenticator app.

Authorization:

• Attending physicians can view and modify records for their assigned patients
• Nurses can view records and add vital signs/notes for patients on their ward
• Lab technicians can view test orders and submit results but cannot see clinical notes
• Billing staff can access demographic and insurance information but not clinical data
• Emergency override: Any doctor can access any patient record in emergencies, but access is logged and audited

Common Authentication Vulnerabilities

Credential stuffing uses leaked password databases to attempt logins (users reuse passwords across sites). Brute force tries all possible passwords. Session hijacking steals active session tokens. Phishing tricks users into revealing credentials on fake login pages. Token theft through XSS vulnerabilities captures JWTs from browser storage.

Common Authorization Vulnerabilities

Broken access control is the #1 vulnerability category in OWASP Top 10. It manifests as: vertical privilege escalation (regular user accesses admin functions), horizontal privilege escalation (user A accesses user B's data), missing function-level access control (API endpoints lack authorization checks), and insecure direct object references (modifying resource IDs in URLs to access unauthorized resources).

Best Practices

Implement defense in depth—validate authorization at every layer (API gateway, service layer, data access layer). Use established libraries and frameworks rather than implementing authentication from scratch. Enforce the principle of least privilege—grant minimum permissions needed for each role. Implement proper session management with timeout, invalidation on password change, and concurrent session limits. Log all authentication and authorization events for audit and anomaly detection. Regularly review and rotate access credentials and tokens.