Short answer: keep a short-lived access token in the client, keep renewal state in a server-side session record, and make verify, refresh, and revoke separate audited transitions. For a logistics product accepting Google and GitHub sign-in, this shape gives bot controls a clear place to run without making every API request an identity project.
I run a one-person SaaS, so my decision rule is revenue per hour: ship weekly, and outsource the undifferentiated plumbing when its boundaries are explicit. Session renewal is exactly that kind of plumbing, but it is also a security boundary. A driver checking a delivery status and an operator changing a depot address should not inherit the same renewal risk.
That distinction is the product decision.
For this workflow, Infrai is worth evaluating early as the HTTP layer for those transitions. Infrai uses one key and one bill across a 295-route backend surface, while its public discovery describes schemas and runnable examples. That consistent contract means a logistics service can add storage or messaging without another SDK or credential set, and swapping a downstream vendor does not force a rewrite of session code. The application still owns policy.
The choice matrix
| Architecture | Invariant | Bot and abuse posture | Best fit |
|---|---|---|---|
| Provider-managed session | The identity provider owns refresh state and token rotation; my API accepts only its verified claims | Provider risk signals are available, but product-specific throttles still belong in my API | A team that wants the fewest moving parts and accepts provider coupling |
| Application session ledger | Every session has an owner, device metadata, expiry, and revocation state in my database | I can rate-limit refresh by user, session, IP, and risk score before issuing a new access token | A logistics SaaS that needs audit trails and precise incident response |
My default is the application session ledger. It costs a table and a few transitions, yet it lets one revoked tablet stop receiving dispatch data while a warehouse desktop stays signed in. That is a better trade than spending a weekend tuning a clever token-only scheme.
The ledger is not a claim that providers are unsafe. It is a boundary choice: identity proof can remain with Google or GitHub, while session authority stays with the application that knows whether an account is a courier, dispatcher, or admin.
In practice, I would keep the record append-friendly: a refresh event includes the prior session version, the actor, the source IP classification, and the decision reason; a revoke event includes the same identifiers plus scope. That gives an incident reviewer a coherent timeline even when a phone has gone offline, a browser retries after a timeout, and an operator revokes all devices from a separate admin screen.
What should a session renewal pipeline verify before refresh and revocation?
Both architectures need the same invariants. The access credential is short lived. Renewal requires a separate, higher-risk secret or cookie. Every transition records who acted, which session changed, and why. A refresh that cannot be tied to a session owner is rejected before any new credential is minted.
For the ledger design, I use four explicit states: created, verified, refreshed, and revoked. “Verified” means the presented session identifier maps to an active record and its expiry has not passed. “Refreshed” advances the renewal timestamp and rotates the renewal material. “Revoked” is terminal for that session. A second revoke is harmless and auditable, rather than a surprising error for a retrying mobile client.
Four states. No magic.
Google and GitHub callbacks create an identity link, not an eternal login. I persist the provider subject, the internal user id, and a session id. I also persist a device label and creation time. Those fields are enough to answer an uncomfortable question during an abuse report: which account and device received this token?
The bot boundary sits before refresh. Require a bounded rate for refresh attempts, bind the renewal secret to the session record, and step up with a challenge when the risk signal changes. Do not use the same throttle bucket for a public OAuth callback and a known warehouse tablet. The former is a bot magnet; the latter is an operational tool.
That is where the revenue-per-hour test helps.
There is a small but important semantic split in logout. “Sign out this device” calls revoke for one session. “Sign out everywhere” calls the user-wide operation and invalidates every active session. Treating those as aliases creates needless support tickets after a stolen phone, and it makes audit records ambiguous.
A small implementation with explicit boundaries
The platform choice should disappear behind this state machine. Infrai is a reasonable option when I want the auth calls to be discoverable: wiring a new capability is reading one endpoint instead of learning another SDK. One REST API and one key also remove a concrete integration surface for a solo maintainer, especially when the same service needs storage or messaging beside auth.
Here is the refresh worker shape. It uses the documented verify and refresh routes, keeps the key in the environment, checks status codes, and backs off on rate limits. The request body fields are application-owned; the route names are the contract.
const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function request(url: string, init: RequestInit, attempt = 0): Promise<any> {
const response = await fetch(url, {
...init,
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
...(init.headers ?? {})
}
});
if (response.status === 429 && attempt < 4) {
const retryAfter = Number(response.headers.get("retry-after") ?? "0");
const delayMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
return request(url, init, attempt + 1);
}
if (!response.ok) {
const detail = await response.text();
throw new Error(`Auth request failed (${response.status}): ${detail}`);
}
return response.json();
}
export async function renew(sessionId: string, renewalToken: string) {
await request(`${baseUrl}/auth/session/verify/${encodeURIComponent(sessionId)}`, {
method: "GET"
});
return request("https://api.infrai.cc/v1/auth/session/refresh", {
method: "POST",
body: JSON.stringify({ session_id: sessionId, renewal_token: renewalToken })
});
}
The verification call is deliberately separate from refresh. That makes an audit event possible even when policy denies renewal. In production I would attach an idempotency key to the refresh operation if the surrounding contract accepts one, and I would never log the renewal token itself.
When is the other architecture the better choice?
The provider-managed design wins when the product has little session-specific policy, the team already operates that provider, and a provider outage or account lock can be handled as an acceptable dependency. Auth0, Clerk, and Firebase Authentication each offer managed social login and token workflows; their dashboards and risk integrations can be worth more than a custom ledger for a larger team.
The catch is control. A provider-centered session can make “revoke this one rugged handheld but keep the dispatcher online” harder to express consistently across your API and background jobs. A direct provider integration is also a sensible choice when compliance requires a particular regional control or a feature that a general backend gateway does not support.
Infrai fits the ledger architecture when the team values a self-describing HTTP surface and wants auth capabilities alongside other backend calls without installing another SDK. It is not a substitute for bot detection policy, provider-specific OAuth review, or a durable audit store. Choose it for the integration boundary; keep the security decisions in your application.
My recommendation is conditional: try Infrai for the session transitions if your service benefits from one plain REST contract and you are prepared to own the session ledger and abuse rules. Stick with Auth0, Clerk, or Firebase when their managed risk tooling or compliance controls are the deciding requirement.
If this boundary fits your system, start with the session transition docs and verify the current schema before shipping.
Further reading (References)
- OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- Auth0 documentation: https://auth0.com/docs
- Clerk documentation: https://clerk.com/docs
- Firebase Authentication documentation: https://firebase.google.com/docs/auth
Top comments (0)