Entitlement
A user bought a Pro subscription; how should the backend check if they can access this export feature?
Authorization checks permissions by identity and role (such as admin or member); Entitlement checks access rights and quotas granted by commercial contracts and billing plans (such as Free or Pro).
Authentication proves who the caller is; Entitlement determines what that identity is licensed to access.
When to use it
- Verify feature entitlements on the server for each protected API callEvery sensitive action goes through an authorization check.Current user→Authorization rule→Allow / deny
- Sync subscription changes via webhooks to keep entitlement records freshRecord administrative actions16:42 · admin_u7disabled user_u23reason: repeated abuse
- Separate boolean feature gates from metered usage limits and token quotasDeny by default; allow as neededDefaultDENYExplicitly allowviewer → read
- Revoke privileges immediately when a billing cycle ends or a refund occursBeyond roles, check the relationship to the resource.Current useru_23Post authoru_23ResultEdit allowed
When NOT to use it
- Rely only on hiding paid buttons in the client while leaving the API openHiding a button does not secure the endpoint.PageNo delete button → Direct requestDELETE /users/42 → 204
- Hardcode secret admin keys or customer bypass tokens in browser codeAn identity claimed by the frontend can be forged.POST /api/admin/delete{ "userId": "u_23", "role": "admin" }
- Make live HTTP requests to the payment provider on every user actionThe same rule is scattered across several placesusers.tsCheck adminorders.tsForgot to checkreports.tsDifferent rule
- Confuse internal team roles with billing plans: an admin without a plan lacks Pro accessSigning in does not mean you can view all data.Signed in→Access someone else's bill→Should be 403