Authentication vs Authorization for Student Projects

Authentication verifies identity. Authorization decides what that identity may do.

Authentication asks:

Who is making this request?

Authorization asks:

May this identity perform this action on this resource under the current conditions?

A secure request normally follows this flow:

1. Validate the session, token or identity-provider response.

2. Load the current account and trusted identity.

3. Identify the requested action and resource.

4. Evaluate roles, permissions, ownership, tenant and context.

5. Allow or deny the operation and record important events.

Authorization is not completed at login. Every protected operation needs an appropriate access decision.

OWASP Top 10:2025 places Broken Access Control at A01 and Authentication Failures at A07, demonstrating why secure applications must treat these as separate layers.

Authentication vs authorization

Authentication establishes a trusted identity. Authorization applies access-control policy to that identity.

A valid user can still request an invalid action. That is why “logged in” must never mean “allowed to access everything.”

Authentication

Authentication may establish identity through:

• A server-side session
• An access token
• A password and one-time code
• A passkey
• An external identity provider

Its result should be a trusted user or service identity.

Authorization

Authorization evaluates:

• Roles
• Permissions
• Resource ownership
• Tenant membership
• Relationships
• Resource state
• Contextual conditions

Its result is an allow-or-deny decision.

The authentication layer authorization depends on

Authorization can make a reliable decision only when the request contains a trusted identity.

The application should establish:

• The authenticated user
• The account’s current status
• The active tenant or organization
• The session or token validity
• Any trusted roles or identity attributes

A JWT is only a token format. It may carry a user ID, role or scope, but it does not automatically prove that the user may access a particular database record.

The backend must validate the token and still evaluate ownership, tenant boundaries and the requested action.

OAuth 2.0 primarily supports delegated API access. OpenID Connect adds an identity layer for authentication and single sign-on. An ID token communicates information about authentication to a client; an access token is intended for a protected resource or API.

Current OAuth security guidance recommends authorization-code-based flows with appropriate protections, including PKCE, rather than copying outdated implicit-flow implementations.

For a deeper comparison of sessions, JWT, OAuth, MFA and passkeys, read FileMakr’s authentication-system guide.

How an authorization decision works

A useful authorization rule evaluates four elements:

Subject: Who is requesting access?

Action: What do they want to do?

Resource: Which record, file, endpoint or function is involved?

Context: Which additional conditions apply?

Consider this example:

• Subject: Faculty member 47
• Action: Update marks
• Resource: Database Systems, Semester 6
• Context: Assigned instructor, same department and result status is draft

Checking only user.role === “faculty” is too broad.

The system should also verify course assignment, department, tenant and record state.

Role vs permission

A role is a responsibility such as Student, Faculty or Administrator.

A permission is a specific capability such as:

• marks.read.own
• marks.update.assigned
• marks.approve
• users.manage

Roles group permissions. Authorization policies apply those permissions to a particular action and resource.

Access control vs authorization

Access control is the broader system of policies, decisions and enforcement.

Authorization is the decision made when an identity requests an action.

Four authorization levels every project should consider

1. Function-level authorization

This controls access to features or endpoints.

Examples:

• Only administrators can create accounts.
• Only faculty members can enter marks.
• Only finance staff can approve refunds.

2. Object-level authorization

This controls access to a particular record.

A student may read a result only when:

result.student_id === authenticatedUser.id

Changing an ID to access another user’s record is horizontal privilege escalation. In web applications, this commonly appears as an insecure direct object reference or broken object-level authorization vulnerability.

OWASP recommends checking access for every requested object. Complex identifiers such as UUIDs may reduce predictability, but they do not replace permission checks.

3. Property-level authorization

A user may be permitted to access a record without being allowed to see or edit every field.

Student-facing or public responses should exclude:

• Password hashes
• Internal remarks
• Security flags
• Administrative fields
• Private contact information

Use response allowlists instead of returning every database field.

4. Tenant-level authorization

A multi-college or multi-company application must isolate each tenant’s records.

A valid user from College A must not access College B’s records simply because they know a valid record ID.

Horizontal and vertical privilege escalation

Horizontal privilege escalation occurs when a user accesses another user’s resources at the same privilege level.

Example:

Student A → Student B’s result

Vertical privilege escalation occurs when a lower-privileged user performs a staff or administrator action.

Example:

Student account → /admin/users/delete

Hiding an administrator button in the interface is not authorization. The backend must reject the request.

Choosing an authorization model

RBAC

Role-based access control assigns permissions to roles.

It is a practical starting point for stable roles such as:

• Administrator
• Faculty
• Student
• Parent

Its limitation is role explosion. Creating separate roles for every department, ownership rule and temporary condition becomes difficult to manage.

ABAC

Attribute-based access control evaluates attributes such as:

• Department
• Ownership
• Time
• Risk
• Record state
• Tenant

Example:

A faculty member may edit marks only when assigned to the subject and while the result is in draft status.

ReBAC

Relationship-based access control bases permission on relationships such as:

• Owner
• Supervisor
• Collaborator
• Instructor
• Assigned counsellor

ACL

An access-control list stores resource-specific users or groups. It is useful for files or records with custom sharing.

For most student projects, use RBAC for broad feature access plus ownership, tenant and state checks for fine-grained authorization.

Build an access-control matrix before coding

Convert vague role descriptions into testable rules.

For example:

• Student: View their own attendance and marks.
• Faculty: Update assigned classes while records remain in draft.
• Head of Department: Review department records and approve results.
• Administrator: Manage accounts and access system-wide reports.

Begin with deny by default.

For every allowed action, define:

• The backend policy
• A positive test showing permitted access
• A negative test showing prohibited access
• The evidence needed in the project report

OWASP recommends least privilege, deny-by-default policies and permission validation on every protected request.

Step-by-step implementation guide

Step 1: Inventory identities, resources and actions

List identities such as:

• Guest
• Student
• Faculty
• Administrator
• Background service

Then list protected actions:

• Read
• Create
• Update
• Approve
• Export
• Delete
• Assign

Step 2: Centralize authentication

Use middleware to validate the session or token and attach a trusted user object to the request.

Controllers should not trust a user ID, role or tenant ID supplied directly by the browser.

Step 3: Centralize authorization policies

Create reusable policies instead of scattering role checks across controllers.

function canReadResult(user, result) {

if (!user || user.status !== “active”) return false;

if (user.tenantId !== result.tenantId) {

return false;

}

if (user.role === “admin”) {

return true;

}

return result.studentId === user.id;

}

This policy checks:

• Account status
• Tenant isolation
• Administrative access
• Object ownership

Step 4: Enforce policies on the backend and in queries

The backend is the security boundary. A user can bypass the interface with Postman, browser developer tools or a custom script.

Prefer queries already scoped to the current user or tenant.

Vulnerable query:

SELECT * FROM results WHERE id = ?

Safer student query:

SELECT *

FROM results

WHERE id = ?

AND student_id = ?

AND tenant_id = ?

Database scoping reduces the chance that an unauthorized object enters the application flow.

Step 5: Handle role changes and stale tokens

A long-lived token may continue carrying an outdated role.

Consider:

• Short-lived access tokens
• Refresh-token rotation
• Session invalidation
• User or session versioning
• Server-side checks for high-risk operations

Step 6: Return appropriate status codes

Use:

• 401 Unauthorized: Valid authentication is missing.
• 403 Forbidden: The user is known but lacks permission.
• 404 Not Found: Used selectively when revealing the resource’s existence would expose unnecessary information.

Step 7: Log and test access decisions

Record:

• Failed login attempts
• Role changes
• Denied operations
• Administrative actions
• Suspicious object-ID changes
• Session revocations

Do not log passwords, session secrets or complete access tokens.

Test these negative cases:

• A student requests another student’s record.
• A faculty member calls an administrator endpoint.
• A user from another tenant requests a known ID.
• A disabled user reuses an old session.
• A user with a revoked role presents a stale token.
• A hidden frontend action is called directly through Postman.

Positive tests prove permitted access. Negative tests prove prohibited access.

Advanced design: separate decisions from enforcement

A scalable design separates three concerns:

Policy Enforcement Point: Middleware, route guard, gateway or service that intercepts the request.

Policy Decision Point: The component that decides whether access is allowed.

Policy information: Roles, ownership, tenant, relationships, resource state, time and risk.

Small applications can use reusable policy functions. Larger systems may adopt policy-as-code tools. In either case, authorization logic should remain centralized, testable and auditable.

Frequently asked questions

Is authentication the same as authorization?

No. Authentication verifies identity. Authorization determines which resources and actions that identity may access.

Which comes first?

Authentication normally comes first for protected user operations. Authorization then evaluates the requested action, resource and context.

Can authorization happen without login?

Yes. An application can allow anonymous users to read public resources while denying private or write operations. Authentication becomes necessary when the policy depends on a known identity.

Is JWT authentication or authorization?

JWT is a token format. It can carry identity, role or scope claims, while the surrounding architecture determines how it is used.

Is OAuth an authentication protocol?

OAuth 2.0 is primarily an authorization framework for delegated API access. OpenID Connect adds the identity layer commonly used for authentication.

What is the difference between RBAC and ABAC?

RBAC grants permissions through roles. ABAC evaluates attributes such as department, ownership, time, risk and record state.

Should authorization run on every API request?

Every protected operation needs an appropriate permission check. A valid session proves identity, not access to every function or object.

What should a student project document?

Include:

• Authentication sequence
• Role-permission matrix
• Protected routes
• Database relationships
• Authorization policies
• Threat analysis
• Negative test cases
• Screenshots of denied requests

Conclusion

Authentication and authorization belong to the same security pipeline, but they solve different problems.

Authentication establishes a trusted identity.

Authorization continually limits what that identity may do according to permissions, ownership, tenant, relationship, action and context.

For most student and beginner web applications, a strong starting architecture includes:

• Secure password storage
• Protected sessions or carefully designed tokens
• Centralized authentication middleware
• RBAC plus ownership checks
• Deny-by-default policies
• Tenant-aware database queries
• Audit logging
• Negative authorization tests

Design the access-control matrix before writing routes. It improves the architecture, testing evidence, project report and viva explanation — and prevents the dangerous assumption that every logged-in user should be trusted with every reachable record.

For the next implementation step, continue with FileMakr’s REST API guide or inspect relevant live project demonstrations.