Introduction

Authorization is a core secure programming practice that controls what a user is allowed to do after their identity has been verified.

In the previous lesson, we learned that authentication answers the question “Who are you?”. Authorization answers the next important question: “What are you allowed to do?”

For example, a student may be allowed to view their own marks, but not edit marks. A teacher may be allowed to update marks, but not manage system users. An admin may have wider permissions, but even admin access should be controlled carefully.

Easy Real-Life Example

Authentication:
Security checks your ID card.
Question: Who are you?

Authorization:
System checks which rooms your card can open.
Question: What are you allowed to access?

Software:
Login verifies identity.
Authorization checks permissions.

Authentication lets the system know who the user is. Authorization decides what that user can do.

What is Authorization?

Authorization is the process of checking whether a user, system, or application has permission to access a specific resource or perform a specific action.

Resources may include pages, files, APIs, reports, database records, admin panels, dashboards, buttons, forms, or business operations.

Simple Example

User:
Student

Requested Action:
Edit another student's marks

Authorization Check:
Students are not allowed to edit marks.

Result:
Access denied

Authentication vs Authorization

Authentication and authorization work together, but they are different security controls.

Why Authorization is Important

Authorization is important because applications usually have different users with different responsibilities.

If authorization is missing or weak, users may access data or features they should not access.

What Can Go Wrong Without Authorization?

Without proper authorization, an authenticated user may access features or data that should be restricted.

Access Control

Access control is the broader security concept that controls who can access what.

Authorization is the decision-making part of access control. It decides whether a user should be allowed or denied.

Access control question:
Can this user access this resource and perform this action?

Example:
Can Teacher A update marks for Class 10?
Can Student B view Student C's report?
Can Admin delete a user account?

Roles

A role represents a user’s responsibility or position in the application.

Roles help group permissions in a meaningful way.

Example Roles:
- Student
- Teacher
- Principal
- Admin
- Support Staff
- Guest

Instead of assigning every permission manually to each user, applications often assign permissions to roles and then assign users to roles.

Permissions

A permission defines a specific action that can be performed on a resource.

Example Permissions:
- view_marks
- edit_marks
- delete_student
- create_report
- manage_users
- approve_request
- view_dashboard

Permissions should be clear, specific, and connected to real application actions.

Role-Based Access Control

Role-Based Access Control, or RBAC, is an authorization model where access is granted based on user roles.

In RBAC, permissions are assigned to roles, and users receive permissions through the roles assigned to them.

RBAC Flow:
1. Define permissions.
2. Group permissions into roles.
3. Assign roles to users.
4. Check role permissions before allowing actions.

RBAC Example

Principle of Least Privilege

The principle of least privilege means users should receive only the minimum permissions required to perform their tasks.

Unsafe Permission Assignment

Every teacher receives admin access because it is convenient.

Safer Permission Assignment

Teachers can enter marks and generate class reports.
Only admins can manage users and system settings.

Least privilege reduces damage if an account is misused or compromised.

Common Authorization Models

Different applications may use different authorization models depending on their needs.

Ownership-Based Authorization

Ownership-based authorization checks whether the requested resource belongs to the current user.

Example:
A student wants to view report card with studentId = 205.

Authorization check:
Is currentUser.studentId equal to 205?

If yes:
Allow access.

If no:
Deny access.

This is important for applications where users have personal records, orders, messages, documents, or profiles.

Server-Side Authorization

Authorization must be enforced on the server side or trusted backend.

Hiding a button on the user interface is not enough because users may still try to call backend APIs directly.

Unsafe Approach

Hide "Delete User" button from normal users,
but backend delete API does not check permission.

Secure Approach

Hide "Delete User" button from normal users,
and backend API also checks permission before deleting.

Basic Authorization Logic

Weak Version

FUNCTION deleteStudent(studentId)
    DELETE student record
    RETURN "Student deleted"
END FUNCTION

This code deletes a student record without checking whether the current user has permission.

Improved Authorization Version

FUNCTION deleteStudent(currentUser, studentId)
    IF currentUser.role is not "Admin" THEN
        RETURN "Access denied"
    END IF

    DELETE student record

    RETURN "Student deleted"
END FUNCTION

The improved version checks permission before performing a sensitive action.

Permission-Based Authorization Example

FUNCTION canPerformAction(user, requiredPermission)
    IF requiredPermission is in user.permissions THEN
        RETURN true
    ELSE
        RETURN false
    END IF
END FUNCTION

IF canPerformAction(currentUser, "edit_marks") THEN
    UPDATE marks
ELSE
    DISPLAY "Access denied"
END IF

Permission-based checks are useful when applications need more control than simple role checks.

Role and Ownership Combined Example

FUNCTION canViewReport(currentUser, reportOwnerId)
    IF currentUser.role is "Admin" THEN
        RETURN true
    END IF

    IF currentUser.userId == reportOwnerId THEN
        RETURN true
    END IF

    RETURN false
END FUNCTION

This allows admins to view reports and also allows users to view their own reports.

Real-World Example: E-Commerce Authorization

Student-Friendly Example: School Portal Authorization

Student:
- Can view own marks
- Can view own attendance
- Cannot edit marks

Teacher:
- Can view students in assigned class
- Can enter marks
- Can generate class report

Admin:
- Can create users
- Can assign roles
- Can manage system settings

Each role receives only the access needed for its responsibility.

Broken Access Control

Broken access control happens when users can access resources or actions they should not be allowed to access.

Examples:
- User changes URL parameter to view another user's data.
- Normal user opens admin API endpoint.
- Hidden page is accessible directly by URL.
- User edits records belonging to someone else.
- Backend trusts frontend role information without verification.

Broken access control is dangerous because it may expose data, allow unauthorized changes, or bypass business rules.

Insecure Direct Object Reference

Insecure Direct Object Reference, often called IDOR, happens when a user can access another user’s resource by changing an identifier.

Risky Example

/student/report?studentId=101

User changes URL to:
/student/report?studentId=102

If the system does not check ownership or permission,
the user may access another student's report.

Safer Check

Before showing report:
Check whether current user is allowed to view studentId.

If not allowed:
Return "Access denied".

Permission Review

Authorization is not only a coding task. Permissions should be reviewed regularly.

Authorization Checklist

Common Beginner Mistakes

Best Practices for Authorization

Prerequisites Before Learning Authorization

Students should understand the following topics before learning authorization deeply:

Trace Table Example: Delete Student Authorization

FUNCTION canDeleteStudent(currentUser)
    IF currentUser.role == "Admin" THEN
        RETURN true
    ELSE
        RETURN false
    END IF
END FUNCTION

Practice Activity: Add Authorization

Improve the following pseudocode by adding an authorization check.

FUNCTION updateMarks(studentId, marks)
    SAVE marks for studentId
    RETURN "Marks updated"
END FUNCTION

Sample Improved Version

FUNCTION updateMarks(currentUser, studentId, marks)
    IF currentUser.role is not "Teacher" AND currentUser.role is not "Admin" THEN
        RETURN "Access denied"
    END IF

    IF marks < 0 OR marks > 100 THEN
        RETURN "Invalid marks"
    END IF

    SAVE marks for studentId

    RETURN "Marks updated"
END FUNCTION

The improved version checks whether the user has permission before updating marks.

Practice Test Cases

Mini Quiz

Interview Questions on Authorization Basics

Quick Summary