Authentication verifies an identity; authorization determines access to an action or resource. In a SaaS application, checking Laura’s credentials establishes which account is making a request. Deciding whether that account can deactivate a colleague requires a separate check against the product’s access rules.
The distinction affects the way a feature is specified. Login methods, session handling and multi-factor authentication concern the evidence used to establish identity. Roles, company membership and ownership of a particular record concern what an identified account can access. A successful login leaves those permission decisions unresolved.
Roles and actions in a shared workspace
Consider a hypothetical project management product with Owner, Admin and Member roles. Members can create tasks and comment on projects, Admins can invite and deactivate users, and the Owner can delete the account. All three roles can log in, but they have different authority within the workspace.
Those labels are only a starting point. The team still needs to decide whether an Admin can deactivate another Admin, whether someone can change their own role and how ownership is transferred when the Owner leaves. These decisions affect account recovery, support procedures and the risk of leaving a workspace without anyone able to manage it.
A permission change also has consequences for work already in progress. If an Admin loses export access while a file is being prepared, the product needs a rule for whether that job continues and whether the file can still be downloaded. Engineering can implement the checks once the expected behaviour is clear.
Authorization applies to particular resources
A role that permits viewing invoices does not establish which invoices the account may view. Laura might be entitled to invoices for Company A while having no access to Company B’s records. In a multi-tenant product, where several organisations share an application, that boundary must be enforced for each relevant operation.
Changing an identifier in a URL or request must not make another company’s invoice accessible. Hiding a link in the interface is insufficient: the server handling the request must check access to the requested resource. Similar boundaries apply to projects, customer records, reports and API keys.
Some rules depend on context as well as a role. An organisation might allow members to edit their own projects while restricting billing changes to its Owner. Documenting the action, resource and conditions gives the team something more precise to review than a broad statement such as “Admins have access”.
Specifying an export feature
An “Export users” button illustrates how access rules become part of a feature. The specification needs to establish which roles can request an export, which organisation’s records it includes and which fields may appear. Personal data, billing information and credentials have different consequences if disclosed.
The interface should reflect those rules, while the operation itself enforces them. Tests can then check both permitted and rejected requests: an eligible Admin exporting their own company, a Member attempting the same operation and an Admin requesting records from another company. Permission changes during a session also need a defined outcome.
These cases expose questions that are easy to miss in a screen design. They also give Product, Engineering and Security a shared basis for reviewing whether the implementation follows the intended access model.
Reviewing access with Engineering
For a feature involving accounts or sensitive actions, record how the caller is identified, what they are requesting and the conditions under which that request should be allowed. Include representative cases that must be rejected. Authentication mechanisms can then be reviewed alongside the authorization checks they support.
The book Security for Product Managers develops access control alongside the other security decisions that arise during product work. OWASP’s authorization guidance provides a technical reference for reviewing these checks.
