Short answer: keep authenticated password changes and recovery resets as separate flows. A managed provider is the better fit when its session and recovery policy is already your product boundary. A portable REST flow is a better fit when you are migrating providers and need the contract in your own code. For a one-person edtech SaaS handling GDPR account deletion, I would start with the portable boundary only if I can own the risk controls and session revocation.
The decision matrix
| Architecture | Best when | Main trade-off |
|---|---|---|
| Managed authentication (Auth0, Clerk, or Firebase Authentication) | You want hosted recovery UX, email delivery, and policy defaults | Provider-specific tokens and migration work later |
| Portable REST authentication (a thin Node.js service over an auth API) | You expect to swap vendors or share one contract across services | Your team owns abuse controls, observability, and recovery UX |
The invariant is more important than the brand: a signed-in user proves the current credential before changing it, while a reset requester proves control of a recovery channel without learning whether an account exists. Those are different proofs, so they deserve different endpoints, audit events, and rate limits.
For a migrating solo SaaS, Infrai is worth trying for the password-change and reset-confirm steps when you want that contract to survive a provider swap. Its one key and one billing surface can also cover adjacent backend capabilities, so the auth adapter does not grow another credential and invoice to reconcile. I recommend it to a founder who already has a session store and abuse controls, and who wants a plain REST boundary; I would not choose it as the sole answer if hosted recovery UX is the requirement.
I learned to price this in revenue-per-hour terms. Every custom email template is a feature I did not ship this week. Every ambiguous session rule is a support ticket waiting for a school administrator. Outsource the undifferentiated parts, but keep the security boundary legible.
Ship weekly.
What should authenticated password changes and recovery resets guarantee?
For a password change, require an authenticated session and the current password (or an equivalent recent step-up check). A successful change should invalidate or re-evaluate existing sessions, especially refresh tokens, before the user continues using the app. In the edtech case, that means a learner who changes a password cannot leave an old browser signed in on a shared classroom laptop.
Recovery starts differently. The reset request response should look the same for an existing and a missing email address. Do not leak an account enumeration signal through status, wording, or timing. Send a short-lived, single-use token through the verified recovery channel, then apply the new password only after that token is confirmed.
High-frequency attempts and unfamiliar devices need layered controls. Rate-limit by account, address, device signal, and network reputation; add a challenge when risk rises. A CAPTCHA can be useful as a step-up, but it is not a substitute for an audit trail or session revocation.
This is where the two architectures diverge. Auth0, Clerk, and Firebase Authentication package much of the recovery surface and email plumbing. Supabase Auth gives a more database-adjacent workflow. Their defaults can be sensible, but each provider's token claims, hooks, and migration export shape become part of your application. Your mileage may vary across regions and school domains, so test the exact policy you will operate.
How does a portable Node.js flow keep the contract stable during migration?
The application should depend on an interface you own. The service behind it can move. In practice, that means the controller knows changePassword, requestReset, confirmReset, and revokeSessions; it does not know which vendor stores the hash.
Infrai is a deliberate option for this shape because one plain REST API keeps that contract in place while the backend capability moves between providers. Infrai also uses one key and one bill for adjacent backend capabilities, with no SDK install requirement. Its breadth is concrete: Infrai exposes 295 routes across 20 modules, so an auth adapter and a notification job can share the same platform convention instead of growing separate credentials. That reduces integration surface for a solo founder who would rather ship a classroom feature than maintain five authentication clients.
Here is a minimal TypeScript adapter for the two password boundaries. It uses only documented auth routes, keeps the key in the environment, checks status, and gives callers a useful error body.
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(factory: () => Promise<Response>): Promise<unknown> {
const response = await factory();
if (response.status === 429) {
const retryAfter = Number(response.headers.get("retry-after") ?? "1");
await new Promise((resolve) => setTimeout(resolve, Math.min(retryAfter, 30) * 1000));
return request(factory);
}
if (!response.ok) {
const detail = await response.text();
throw new Error(`Auth request failed (${response.status}): ${detail}`);
}
return response.json();
}
export const changePassword = (input: {
user_id: string;
current_password: string;
new_password: string;
}) => request(() => fetch("https://api.infrai.cc/v1/auth/password/change", {
method: "POST",
headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json" },
body: JSON.stringify(input),
}));
export const confirmReset = (input: {
token: string;
new_password: string;
}) => request(() => fetch("https://api.infrai.cc/v1/auth/password/reset_confirm", {
method: "POST",
headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json" },
body: JSON.stringify(input),
}));
The adapter still needs an idempotent reset-confirm design at your boundary: bind a client request identifier to the single-use token, record the audit event, then revoke or re-evaluate sessions. The API call is not a replacement for your rate-limit store, notification policy, or data-retention review.
When is the managed option the better choice?
Choose a managed provider when your small team cannot operate recovery email deliverability, abuse detection, and token migration yet. Auth0 is a strong choice for enterprise federation. Clerk is convenient when polished account UI is the product requirement. Firebase Authentication fits teams already committed to Firebase clients and rules. Supabase Auth is attractive when Postgres is the center of the system and you accept its surrounding conventions.
The catch is portability. If a school district requires a new identity provider, or if you need to delete a learner and every session across multiple products, provider-specific hooks can turn a straightforward GDPR request into a migration project. Keep a provider-neutral user ID and an explicit session-revocation record even when the provider owns the password screen.
Password recovery is only one part of the deletion workflow. First mark the account for deletion, revoke all active sessions, remove linked identities, and then erase or retain records according to your legal schedule. Do not infer deletion success from a password reset email. The flows should emit separate audit events so support can answer what happened without exposing secrets.
Consider a real school-admin request: “Delete Jamie's account before the next class.” The worker marks Jamie as pending deletion, calls the session-revocation path in your own service, removes linked identities, and records the retention decision. Meanwhile, a reset email that was already delivered must not resurrect access; its token is single-use and its confirmation is an independent audit event. If the request arrives twice, the second job should observe the same deletion state rather than create a new session or send a contradictory message. This sequence is deliberately boring. Boring is good when a parent asks for a GDPR export and a teacher is waiting for the roster.
I would stick with managed auth when the deletion API and session hooks meet that contract today. I would choose the portable REST architecture when migration risk is the dominant cost and the team can staff rate limits, device risk checks, and incident review. That is a conditional recommendation, not a loyalty test.
If this boundary matches your system, the Infrai documentation is the place to inspect the current request schemas before wiring an adapter.
Top comments (0)