Separate Authentication from Authorization

A practical approach

Step 1

Name the actions your feature supports and the resource each action affects. Define the required ownership or role relationship.

Step 2

Enforce checks on the server for every protected read and write. Treat hidden buttons as usability choices, not security controls.

Step 3

Test access with two ordinary users and different resource ownership. Include direct requests that bypass the interface.

Worked example

A learner can view their own progress but should not see another learner’s progress by changing an ID in the URL. The server must compare the authenticated identity with the requested record’s permitted scope.

A mistake to avoid

An administrator role can become an overly broad shortcut. Prefer permissions that match actual responsibilities and review whether privileged actions need additional logging or confirmation.

Try it yourself

Create an action-resource matrix for one feature. Test an owner, another signed-in user and an unauthenticated request against each protected operation.

Your implementation checklist

• Identity and permission are separate checks.
• Resource ownership is verified.
• Protected operations enforce rules server-side.
• Direct requests receive the same protection as the UI.