SReverseby Simpa Labs

Authentication

Authenticating against a private Android API

When an API has no public documentation, the app is the specification for how to authenticate against it. A working session comes from reading the client's login and header logic and confirming it against the server's own error responses.

The app carries the API specification

An app that talks to a private backend contains the credential exchange, the token handling and the code that attaches the result to every request. That code is the only public description of the interface, and the server completes it by rejecting anything the client does not send. Reading the two together is what turns a set of observed requests into an interface you can call.

Start with the questions that decide everything else. Which endpoint issues the credential, what does it accept, what does it return, and where does the resulting value get placed on later requests? Answer those four and the rest of the API becomes reachable, because the same credential unlocks the rest of the surface.

Locate the pieces in the client

Each part of the authentication chain leaves a trace in the code, so work from the request backwards.

  • Find where the Authorization header or its equivalent is set. That line names the field holding the session value and shows whether it is added by an interceptor, a request builder or a generated client.
  • Read the token issuing routine and note its inputs. Login can return a token directly, return a token plus a refresh value, or return an opaque session identifier that the client exchanges for a signed value before use.
  • Follow the code that transforms the credential before it is used. A client may hash, sign or wrap the token, in which case a raw copy of the value is not enough to authenticate.
  • Trace what happens on rejection. Refresh logic, retry logic and re-login logic are all in the client, and they define how long a session survives.

Build and verify the session

Reproduce the setup the app performs before the call you want. Most private APIs are stateful in practice: the app registers a device, fetches configuration, or establishes a session in an earlier request, and a client that skips those steps sends a credential the server will not accept yet.

Confirm each step against the server rather than assuming success. A request accepted with a token that was issued in the same sequence confirms the chain end to end. A request rejected with a specific error narrows the problem to one field.

Diagnose the failures you will hit

Private API authentication fails in recognisable ways.

  • A rejection with a valid-looking token usually means the token belongs to a different session, a different app build, or a different device identity, so compare the values that were bound at issue time.
  • Expiry arrives on the server's schedule, which is often shorter than the client's refresh interval suggests, so test a session past its expected lifetime rather than trusting the code's constants.
  • Optional device headers can be mandatory on some routes, and a request that succeeds against one endpoint can fail against another with the same token.
  • Attestation or integrity headers appear where a client is expected to be genuine, and those cannot be produced off the device, so identify them early instead of discovering them late in the flow.

Refresh logic is the difference between a demonstration and a usable client. Confirm that the refresh call works without the app, that it returns the fields the client expects, and that requests made after a refresh carry the new value. A token that cannot be refreshed turns into a scheduled outage.

Order matters when you rebuild the flow. Capture the sequence the app follows at sign-in and reproduce the calls in that order, because a request that looks irrelevant can be the one that provisions the account or registers the device identity the later calls are checked against. Removing calls one at a time shows which of them the server actually requires.

What the finished work contains

The output of this kind of project is a documented interface: each endpoint with its method, headers, body shape and the credential it requires, plus a client that establishes a session, refreshes it and handles the error paths. Because none of it was published before, each part has to be supported by evidence from the app or from observed traffic. That record is what makes the result maintainable after the app updates.

Reviewed 28 September 2026 · SReverse research desk

Start your full APK reconstruction

Send the full APK

Projects start at $120. Choose WhatsApp or email, then attach the APK in the app that opens. We reply within one hour with the next step and send the fixed quote after review.

Want us to contact you?