Valid JWT.
Wrong Customer.
Data Leak.
Authentication is not authorization. Experiment with a real-world order API decision path: signature, audience, scope, then record ownership.
Configure request
Authorization decision
Order belongs to the caller.
Request
GET /api/orders/A-101 Authorization: Bearer <Alice JWT>
Database lookup
SELECT ... WHERE id = :id AND customer_subject = :sub AND tenant_id = :tenant;
Only Alice's order is returned.
Why this matters
OAuth 2.0 scopes control the type of operation. They do not automatically prove ownership of the requested object. A server must authorize every object lookup using verified identity and tenant context.
403 → authenticated, missing permission
404 → absent or unowned order (demo policy)
200 → token, scope, and ownership all pass
A 404 concealment policy is a deliberate API design choice, not a universal rule.
Test your understanding
Three questions. Choose one answer for each, then grade the quiz.
Three practice challenges
Beginner — Identify the missing authorization step
A valid Alice token requests Bob's order. Under this demo policy, the result is 404 after a tenant-and-owner-scoped lookup returns no rows.
Intermediate — Build a secure order-history endpoint
Use `tenant_id` and authenticated `sub` in the WHERE clause, add stable keyset pagination, and test cross-tenant identity collisions.
Advanced — Temporary support-agent access
Require a narrowly scoped, time-limited approval for a specific order and purpose. Audit every access and deny requests after expiry or revocation.
All data and outcomes are fictional. This lab models authorization decisions; it does not perform JWT cryptographic validation, connect to an IdP or DB, or benchmark performance. Sources: OWASP BOLA · Spring Security JWT.