Learning objectives
- Distinguish authentication from authorization
- Apply Zero Trust to resource boundaries
- Design identity lifecycle tests
The mental model
Authentication establishes who or what is making a request. Authorization decides whether that identity may perform a particular action on a particular resource. A successful login does not imply access to every tenant, application, or administrative operation. Zero Trust avoids granting trust solely because a request originates inside a familiar network. It uses explicit policy and relevant context to evaluate access. This is an architecture principle rather than a single product checkbox. For an experienced application engineer, the useful connection is familiar: validate identity, enforce least privilege, and re-evaluate assumptions at boundaries instead of treating location as sufficient proof of permission.
How it works
An access decision can combine identity, group membership, device posture, resource, and session context. The exact signals and enforcement points depend on the design. NIST's Zero Trust architecture emphasizes protection of resources and removal of implicit trust based solely on network location or ownership. A practical implementation still needs identity lifecycle management, policy ownership, logging, and recovery procedures.
Separate the outer application-access gate from authorization inside the application. An identity-aware proxy may decide that an employee can reach an admin application, while the application must still decide whether that employee can delete a tenant or view a record. Service-to-service identities also require scoped credentials and rotation. Consider joiners, role changes, offboarding, contractors, and emergency access. Test both allowed and denied cases, including a valid identity with insufficient privilege. Define session duration and revocation behavior according to actual supported controls and risk requirements, rather than assuming every access decision is instantly rechecked everywhere. A Zero Trust migration should reduce unnecessary access while preserving a usable path for legitimate work. Measure that reduction and the support burden so policy remains operable.
Applied example · hypothetical
Hypothetical example: a contractor needs access to a staging dashboard for two weeks. A broad VPN profile exposes an entire private subnet, including unrelated services. The team instead designs access around the dashboard, the contractor's identity, and the required duration, while retaining application roles. When the contract ends, the identity and access entitlement are removed. A test also confirms that another authenticated contractor cannot use the same URL. The benefit is a narrower permission boundary with auditable ownership, not a claim that the network has become permanently trustworthy.
In a customer engagement
For Cloudflare Access, ask which applications and identities should be allowed and what policy signals are available. Explain that Access does not remove the need for application authorization. Coordinate with the identity team on groups, offboarding, and recovery. A successful pilot should include denied users and changed roles, not only a demonstration of one employee logging in.
Interview relevance
Interviewers may ask whether Zero Trust means trusting nothing. Replace the slogan with explicit resource access decisions, least privilege, and verified context. Show the difference between authentication and authorization using a tenant boundary. Explain identity lifecycle and emergency access, which reveal whether the design can operate beyond a demo.
Common mistakes
- Treating login as permission to every resource
- Using network location as sufficient trust
- Ignoring offboarding and emergency access
Key terminology
Authentication — Establishing the identity of a user, device, or service.
Authorization — Deciding whether an identity may perform a specific action on a resource.
Least privilege — Granting only the access necessary for the intended task.
Device posture — Signals about a device state used as input to access policy.
Explain it without the page
- Which authorization checks remain inside your application after adding an access proxy?
- How would you test a role change and revocation?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.