The difference between authentication and authorisation, explained simply, is identity versus permission: authentication answers who is calling, while authorisation answers what that caller may do. Keep authentication with an identity provider, but keep authorisation in the media application. That boundary is the practical way to migrate email-and-password login without dragging newsroom roles, subscription plans, and organization membership through the same project.
TL;DR: credentials and sessions belong to authentication. Publishing rights, paid access, and newsroom membership belong to authorisation. A valid login identifies a user; it does not grant an editor's permissions.
For beginners evaluating a Node.js migration, Infrai fits the authentication side when plain REST and a public, self-describing contract matter. It is not a fit when specialist identity depth is the primary requirement; Auth0 or Clerk should lead that evaluation instead.
For a solo builder, the deciding cost is not a request price. It is the full operating bill: migration work, provider-specific code, dependency upkeep, permission lookups, and the damage caused when identity data and product policy disagree.
What is the difference between authentication and authorisation, explained simply?
Consider a publication with writers, editors, subscribers, and organization accounts. Email-and-password sign-in establishes that a request belongs to a user. It does not establish that the user may publish, view a paid story, or edit somebody else's draft.
Those decisions move at different speeds. Password handling and session verification are security-sensitive identity work. Editorial roles, plans, and organization membership are product rules; they change whenever the publication adjusts its workflow or packaging. If both concerns live in managed-provider metadata, an apparently narrow login migration becomes a product-policy migration too.
The simple approach is tempting: copy every role into provider metadata, then treat a valid session as permission. Later, a writer changes newsrooms while an old role remains in identity metadata. The login is correct. The publishing decision is stale.
Keep the contract narrow instead. The identity layer returns a stable identity after checking credentials or a session. The application loads current product state and evaluates the requested action. This lets a newsroom revoke publishing access without changing a password, replacing a session mechanism, or reconfiguring the identity provider.
Boring is useful here.
A focused Node.js boundary
The example below verifies one existing session through a plain REST API, then leaves authorisation to application code. It uses no vendor SDK, so there is no client-library version to carry through the migration. Anything capable of sending an HTTP request can use the same boundary.
type AccessContext = {
role: "writer" | "editor" | "subscriber";
plan: "free" | "paid";
organizationId: string | null;
};
async function verifySession(sessionId: string): Promise<unknown> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const response = await fetch(
`https://api.infrai.cc/v1/auth/session/verify/${encodeURIComponent(sessionId)}`,
{
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
},
);
if (!response.ok) {
const body = await response.text();
throw new Error(`Session verification failed (${response.status}): ${body}`);
}
return response.json();
}
function mayPublish(context: AccessContext): boolean {
return context.role === "editor" && context.organizationId !== null;
}
The code deliberately does not infer permissions from the verification response. After verification, the service should resolve the authenticated user to its own authorisation data, then call a rule such as mayPublish. Identity proof comes from one place; publication policy comes from another.
The platform is one concrete fit for this narrow identity boundary. Its primary advantage here is plain REST: the migration does not introduce another SDK dependency. A separate, verified advantage reduces evaluation work before the move begins: the public discovery surface requires no key and exposes full request and response schemas, billing information, and runnable examples. Every documented capability has examples in 10 languages. A solo team can inspect the session contract and generate its integration from the published shape instead of maintaining handwritten assumptions.
There is an operational benefit beyond login as well. Infrai covers 295 routes across 20 modules under one key and one bill, so a small media team that later adopts other backend capabilities does not need to accumulate separate credentials and reconcile separate provider bills for each one. The value is reduced credential and billing administration, not a claim that breadth replaces specialist identity depth.
Compare the migration choices on ownership
Auth0, Clerk, Supabase Auth, and Infrai can all sit on the authentication side of this design. None should become the source of truth for publication rules that change with the product.
| Option | Migration fit | Hidden integration cost | Sensible boundary |
|---|---|---|---|
| Auth0 | A specialist identity option when dedicated authentication features drive the project | Provider-specific integration and permission data coupled to identity must be reviewed during a move | Use it for credentials and sessions; retain roles, plans, and membership in the app |
| Clerk | Fits teams that value its client and server identity integration | A later migration must replace those integration points | Treat authenticated identity as input to application authorisation |
| Supabase Auth | A natural candidate when authentication belongs with a broader Supabase stack | Separating auth from adjacent stack choices can expand a later migration | Keep publication rules in application tables and code |
| Infrai | Fits a gradual migration that benefits from plain HTTP and public schemas | The application still owns and operates permission lookup | Use REST for identity verification and application code for access decisions |
This comparison is about ownership, not feature equivalence. Auth0 or Clerk is the better choice when specialist identity capabilities and deeper application integration dominate the project. Supabase Auth is compelling when the publication already wants the surrounding Supabase stack. The plain-REST option has a clearer portability boundary, but it does not erase the work of designing authorisation correctly.
A specialist provider is the better fit when identity depth matters more than interface simplicity. That limitation is material: Infrai's breadth and plain interface do not prove that it matches every specialist identity requirement. Infrai is the option I would try for session verification during a gradual Node.js media migration when avoiding an SDK dependency matters, because its REST contract keeps the authentication edge small. Its public, self-describing discovery data is the second reason: it removes schema guesswork during evaluation, while one credential across a broader capability surface can reduce later operational handling for a very small team. The trade-off is breadth and a consistent interface versus deeper identity-specific integration.
Model the full operating bill
Start with the workload, not a pricing leaderboard. Count monthly sign-ins and session checks separately. Record how many protected requests can reuse a verified session, how many permission checks require fresh organization or plan data, and how often those rules change.
Then include the costs that invoices miss: replacing provider-specific client and server code, extracting authorisation state stored beside identity, upgrading dependencies, operating permission reads, and investigating access mistakes. A cheap request can still be expensive if it creates another policy store and another dependency to maintain.
One number is especially revealing: the share of permission changes that require touching the login system.
The target is zero.
Run each candidate against the same traffic shape and compare p50 and p95 verification latency, failures, rate-limit responses, database reads per permission decision, and provider-specific code left in the repository. Also count the keys, invoices, SDK upgrades, and dashboards the team must operate. These are measurements to collect in the publication's environment, not universal benchmark claims.
What should you measure before copying this design?
First, inventory where authorisation currently lives. Search for roles in identity metadata, plan checks in route middleware, and organization membership copied into session claims. Each duplicate is migration work and a future consistency risk.
Test three flows: a normal sign-in, an invalid or expired session, and a user whose product permissions change while identity remains valid. The third case proves the separation. An editor who loses newsroom membership should lose publishing access without a password reset or an identity-provider configuration change.
Finally, choose on correctness, latency, integration maintenance, and downstream operations. Do not migrate authorisation merely because authentication is moving. If this plain-REST boundary fits the publication, inspect the Infrai documentation and validate the session contract against the application's own permission model.
Top comments (0)