Authentication and Authorization

Authentication asks who a caller is; authorization asks whether that caller may perform an action. TypeScript roles and claims can structure checks, but real security depends on verifying tokens or sessions and checking permissions on the server for each request. Never accept a client-supplied role as proof of access.

The function expresses a server-side policy decision assuming the Identity came from a trusted verified session. It is not an authentication mechanism itself.

A hidden frontend button is not authorization; attackers can call the API directly without using the UI.

This source was compiled using TypeScript 5.8.3 with strict checking, then executed with Node.js 22.16.0. Its stdout below is the actual captured output. The core logic is runnable without a framework or a remote API; integration-specific examples appear in a separate lab when needed.

TypeScript source

type Role = "viewer" | "editor" | "admin";
type Identity = { id: number; role: Role };
function mayEdit(user: Identity, ownerId: number): boolean {
  return user.role === "admin" || (user.role === "editor" && user.id === ownerId);
}
console.log(mayEdit({ id: 7, role: "editor" }, 7));
console.log(mayEdit({ id: 8, role: "viewer" }, 7));

Verified output

true
false

Compile: npx tsc --strict --target es2022 --module commonjs authentication-authorization.ts; run: node authentication-authorization.js. For examples importing node: modules, install @types/node as a development dependency; for browser or React projects use the separate lab setup.

The function expresses a server-side policy decision assuming the Identity came from a trusted verified session. It is not an authentication mechanism itself.

Before editing the code, predict what the output will be for one changed input. Run it and compare your prediction with the actual result.

A hidden frontend button is not authorization; attackers can call the API directly without using the UI.

Determine whether the issue belongs to the type system, a trust boundary, or actual runtime behavior before choosing a correction.

Add a moderator role and write tests for viewing, editing owned resources, and editing someone else's resource.

Record expected success and failure outcomes, run the code, and compare the observed behavior. Keep the exercise compatible with strict type checking.

The function expresses a server-side policy decision assuming the Identity came from a trusted verified session. It is not an authentication mechanism itself.

Apply the same reasoning to the practice task, then integrate it into a real app only when the runtime and dependency setup are ready.