The scope of a credential should be inversely proportional to its lifetime

The client is hostile by design. A driver phone is not a trusted terminal in a controlled office: it is in someone pocket, in a van, in a city, it can be rooted, the app can be modified, and it has to hold a credential that stays valid for nine hours with no opportunity to refresh. That last part is not a corner case, it is the core requirement.

The standard answer is a short-lived access token refreshed silently in the background. The entire scheme assumes the client can reach the auth server whenever it likes. A driver with no signal cannot. If his token expires at 08:15 then for the next nine hours his app is logged out and he cannot record the twelve deliveries he is physically making, which means the app is useless at exactly the moment it is needed. The naive fix, a thirty-day token, makes a stolen phone a valid credential for a month with no way to pull it back.

The answer is to separate the two things the token is doing. A device token lives ninety days and proves this physical device belongs to this driver. It opens the sync endpoint and nothing else: it cannot read the fleet, cannot change a price, cannot open the dashboard. An access token lives fifteen minutes and opens everything else. The device token is long-lived precisely because it authorises so little.

Working offline requires no authorisation at all, because it is just writing to a local queue. Authorisation happens when the work arrives, and it is checked against current server state rather than against whatever the token claimed nine hours ago. Three kill switches are read fresh from the database on every single sync, because a token in a driver hand may be nine hours old and cannot be trusted to reflect any of them.

So a thief can tap delivered into a local queue all day. Every mutation is rejected the moment it touches the network, and the blast radius of a stolen device is zero server-side writes. The honest cost is that a device revoked at 09:00 does not find out until it reaches signal, and work it did in between is discarded. That is not a flaw in the scheme: it is not possible to tell an offline device anything, so every scheme has this property, and the alternative of trusting the offline token is strictly worse.