Authentication, Authorisation, and Roles
What rule must hold even when someone bypasses the interface, repeats a request, or receives an external-service error? Design and test identity, resource-level permissions, and least-privilege roles as separate controls for every protected operation.
What You Will Be Able to Decide
- Explain authentication, authorisation, and roles in product and business terms.
- Apply this decision: Design and test identity, resource-level permissions, and least-privilege roles as separate controls for every protected operation.
- Recognise this material risk: a signed-in user receives a broad convenience role and can read or change another user's information.
- Use this review: Trace one support request from submission to stored status, including a duplicate click and a provider timeout.
A founder is reviewing how the product will enforce rules and respond when a request does not go to plan. This lesson gives you a concrete question to take into a build brief, proposal review, or product decision.
What rule must hold even when someone bypasses the interface, repeats a request, or receives an external-service error? The course example is A service that lets customers submit and track support requests; use it to decide what evidence would justify the choice before a builder implements it.
What Does Authentication, Authorisation, and Roles Mean for Your Product?
A founder is reviewing how the product will enforce rules and respond when a request does not go to plan.
Use the illustrative service for this course (A service that lets customers submit and track support requests) to make the choice concrete. What rule must hold even when someone bypasses the interface, repeats a request, or receives an external-service error?
Technical term
Authentication, Authorisation, and Roles
Authentication establishes identity; authorisation determines which data and actions that identity is permitted to access; roles group the permissions needed for a defined responsibility.
How Should a Founder Use Authentication, Authorisation, and Roles?
For a service that lets customers submit and track support requests, ask what would happen if a signed-in user receives a broad convenience role and can read or change another user's information.
For this decision, the useful standard is that important rules hold for valid, invalid, repeated, and unauthorised requests.
- Decision: Design and test identity, resource-level permissions, and least-privilege roles as separate controls for every protected operation.
- Evidence to request: show that important rules hold for valid, invalid, repeated, and unauthorised requests.
- Owner: name who will respond if a signed-in user receives a broad convenience role and can read or change another user's information.
- Record the result in the backend proposal and operational acceptance criteria.
- Practical review: Trace one support request from submission to stored status, including a duplicate click and a provider timeout.
How Do You Choose an Approach to Authentication, Authorisation, and Roles?
What rule must hold even when someone bypasses the interface, repeats a request, or receives an external-service error? Design and test identity, resource-level permissions, and least-privilege roles as separate controls for every protected operation.
The risk is that a signed-in user receives a broad convenience role and can read or change another user's information. Compare a simpler option with the proposed one, including who will operate either choice.
- Describe the user or business outcome that must be protected.
- Identify the most credible failure and its consequence.
- Compare the simplest adequate approach with one realistic alternative.
- Set a review point for when the decision may need to change.
What Evidence Should You Accept for Authentication, Authorisation, and Roles?
What Warning Signs Should You Look For?
- The proposal does not address this risk: a signed-in user receives a broad convenience role and can read or change another user's information.
- Nobody can show whether important rules hold for valid, invalid, repeated, and unauthorised requests.
- The decision has no named owner or review point.
What Should You Ask a Consultant?
- What changes for the user if we choose this approach to authentication, authorisation, and roles?
- How have we reduced or accepted this risk: a signed-in user receives a broad convenience role and can read or change another user's information.
- Can you demonstrate that important rules hold for valid, invalid, repeated, and unauthorised requests?
- Who owns the result, and when will we reconsider it?
Key takeaway
Key Takeaway
Design and test identity, resource-level permissions, and least-privilege roles as separate controls for every protected operation. Ask for evidence against the specific risk: a signed-in user receives a broad convenience role and can read or change another user's information.