Authentication and entitlement answer different questions
Authentication establishes which account is making a request. Entitlement establishes what that account may do. A client can hold a valid, unexpired token for a signed-in user and still be refused, because the refusal came from the second question rather than the first.
The practical signal is a 403 on a request while another request with the same token succeeds. A 401 usually means the credential was missing, expired or stale. A 403 on one endpoint while the rest of the session works means the server knows who you are and has decided this account is not entitled to that resource.
Where an entitlement check sits in the flow
Mobile apps check entitlement in two places, and only one of them controls access.
- The client check drives the interface. The app reads a flag, a plan name or a role from the login response or a profile call and uses it to show or hide a screen, disable a control or present a purchase prompt. This check changes what the user sees.
- The server check controls the data. The endpoint reads the account's entitlement from its own store, or from a signed claim in the token, and decides whether to answer. This check holds when the client is replaced.
Entitlement values often arrive with the session. A login or profile response may include a plan, a list of features, a trial state or a set of roles. The client caches those values, which is why a change made on the server can take effect only after the next login or profile refresh.
How a paid feature gets gated on both sides
A paid feature is gated twice in a well-built app, and the two gates fail differently.
- The client gate stops navigation. A hidden menu entry or a disabled control keeps an ordinary user out of the screen. That gate is a usability decision, and a modified client can remove it.
- The server gate checks the account on the endpoint. The call that returns premium data verifies entitlement before it reads parameters, so the request fails even when it is signed and authenticated correctly.
- The refusal looks like an ordinary error. The server may answer 403, 402, 404 or an empty payload, and it may hide the endpoint from an unentitled account.
- Some endpoints return a reduced answer. The call succeeds and the payload omits the premium fields, which is harder to notice than a refusal and appears as missing data in a client.
What that means for reaching a gated endpoint
The requirement is an account whose entitlements include the feature. Capture the flow while signed in as that account, because the token the app sends carries the account's authority and the server checks it on every call.
Editing an entitlement value inside a token does not work when the server verifies the token signature, and it does not work when the server looks the entitlement up in its own store. Both cases are common, and neither depends on what the client claims. The flow still has to be reproduced exactly: the login, any profile or entitlement call the app makes first, the identifiers the server issues and the request shape of the gated endpoint.
Two details decide whether a reproduction is possible. The first is whether the endpoint checks anything beyond the account, such as a device binding, a region or a subscription state held elsewhere. The second is whether the app obtains a device-held credential before the call, which moves the problem out of the request and into the platform.
Read entitlement from the app to plan the work
Decompiled code names the plan constants, the feature flags and the calls that check them. That inventory shows which endpoints serve paid features, which value the client reads to gate a screen and what the server expects in the request. It also explains a refusal, because a 403 that arrives only on premium endpoints with an otherwise valid session is an entitlement decision rather than a signing problem.
Key extraction and DRM circumvention are outside the scope of this work at any price. SReverse recovers the flow and builds a client for an account that is entitled to it, delivered as a Python, JavaScript or TypeScript module with an importable Postman collection and documentation. Projects start at $120 and most are delivered in 24 to 72 hours.
Related work
Reviewed 28 September 2026 · SReverse research desk