A property management signup bill contains more than OAuth calls to build an authorize URL, exchange a callback code, and create a session: it includes captcha verification, work triggered by attempted registrations, durable account records, and evidence retained to investigate mistakes. The dominant retention term is the one allowed to accumulate. Keeping every attempt permanently makes retained attempt data grow with lifetime attempts; a bounded evidence window makes it grow with attempts inside that window instead. This is an accounting relationship, not a measured workload or a vendor price comparison.

Short answer: when moving a property portal off a managed provider, gate new registrations behind a verified captcha, build the Google OAuth authorize URL with the intended redirect, validate state on the callback, exchange the code, resolve the identity before creating a user, and issue the application's own session. In Node.js, Express handlers and session middleware should enforce those boundaries explicitly. Google supplies an identity. It doesn't decide which property account that identity may access.

The migration should reduce unnecessary permanent writes while preserving mappings that make subsequent logins resolve to the same account. Deleting both indiscriminately exchanges a smaller ledger for an account recovery problem.

What should the signup bill actually retain?

Write the storage term as A × D × E + U × M: attempted registrations per day, multiplied by retained days and evidence bytes per attempt, plus retained users multiplied by mapping bytes per user. These are planning variables, not service limits. The first term dominates whenever A × D × E > U × M; without measurements, claiming either term dominates this particular portal would be guesswork. Changing the retention window moves the first term directly. Moving captcha validation ahead of durable account creation also prevents rejected registrations from inflating the user term.

Keep that distinction.

A property portal might receive an attempted resident registration for a building it manages, but a Google identity says nothing about that person's tenancy. Treat the registration gate, external identity, internal user, and property access as separate decisions. Otherwise a migration can preserve successful login while quietly changing who receives a usable account, which is a more consequential discrepancy than a different authentication invoice. Captcha is a registration control in this design; it isn't proof of residency or an authorization decision.

Measure the variables before choosing a retention window. Count accepted and rejected attempts separately, estimate bytes actually written, and distinguish transient callback material from durable identity mappings. No numeric retention recommendation follows from an OAuth exchange alone. A field with no identifiable diagnostic purpose is a poor candidate for indefinite retention.

How do the authorize URL, callback exchange, and session fit together?

For the Node.js and Express implementation, begin with the application boundary. The handler starting social login builds the authorize URL using the configured redirect and associates an unpredictable state value with that browser's pending attempt. The callback handler validates returned state against that attempt before exchanging the code. State validation remains the application's responsibility; a successful exchange doesn't perform that check for it. OAuth's state guidance appears in RFC 6749, Section 10.12.

Reject a mismatch.

After the exchange, resolve the external identity against the existing user mapping. Create a user only when that resolution establishes that a new user is appropriate, then create the session. Resolving after insertion reverses the dependency: repeat logins can become repeated account creation, leaving property access and account recovery attached to different internal records. That's a data integrity failure even if every individual request succeeds.

Express session middleware belongs on the application side of this handoff. It should establish the authenticated application user from the issued session before protected handlers run; the callback code itself isn't a session credential. Property authorization then evaluates that user against the requested resource. Successful identity resolution must not become permission to view every building's records.

For new registrations, require the captcha gate before permitting durable user creation. Returning users should still resolve to their existing mapping. Keep that distinction visible in the handlers so the captcha integration doesn't turn every returning login into a new registration attempt.

The migration acceptance test is continuity: the same external identity must resolve to the intended internal user before and after the provider change. If the migration cannot establish that mapping, automatic account creation is a poor default. Resolve ownership before granting property access. An email address alone should not silently substitute for an established identity mapping.

Compare the migration contract before comparing dashboards

Auth0, Firebase Authentication, and Amazon Cognito are real managed alternatives, but selecting another provider doesn't establish that existing accounts will survive the transition correctly. Compare the identity model each integration puts into the application, then test the intended migration. Export, import, and session behavior are acceptance checks, not interchangeable features to assume.

Option Integration boundary to evaluate Trade-off for a property portal
Direct Google OAuth External Google identity followed by an application-owned user mapping and session. Explicit control over the handoff; the application owns mapping continuity and session integration.
Auth0 Managed authentication through the tenant and application integration. Useful when retaining that managed boundary; existing account identifiers and callback assumptions still need migration tests.
Firebase Authentication Managed authentication with application dependencies on Firebase user identities. Existing Firebase dependencies may favor keeping it; changing providers requires inspecting those dependencies beyond the callback.
Amazon Cognito Managed authentication organized around the user pool integration. Evaluate it against the intended account model; moving to a different managed service still requires continuity checks.

Infrai offers one key, one bill, and a single REST API with no SDK required; its 295 routes across 20 modules let captcha and authentication share an interface. That reduces the separate credentials and invoices surrounding signup, while direct HTTP requests let migration checks run outside the application's framework dependencies. These are operational reasons to evaluate it. The application still owns state validation, identity resolution decisions, and session issuance.

Keep a managed provider when its account model and session integration fit and there is no justified reason to take on the transition. Move the handoff into an application-controlled integration when the team can own those obligations. Administrative consolidation cannot certify that the right resident reached the right account.

A small preflight helps separate provider configuration from migration correctness. The Python example below reads the OAuth provider listing so an engineer can inspect the configured choices before testing Google's authorize and callback flow. It deliberately doesn't invent callback payload fields or claim to implement an Express application. Set INFRAI_API_ORIGIN to the service's HTTPS origin from your deployment configuration, without a trailing path, and supply INFRAI_API_KEY through the environment. Only the Python standard library is needed.

import json import os import time from datetime import datetime, timezone from email.utils import parsedate_to_datetime from urllib.error import HTTPError from urllib.request import Request, urlopen origin = os.environ["INFRAI_API_ORIGIN"].rstrip("/") if not origin.startswith("https://"): raise ValueError("The API origin must use HTTPS") request = Request( origin + "/v1/auth/oauth/providers", method="GET", headers={"Authorization": "Bearer " + os.environ["INFRAI_API_KEY"]}, ) for attempt in range(3): try: with urlopen(request, timeout=30) as response: if response.status != 200: raise RuntimeError(f"Unexpected HTTP status: {response.status}") print(json.dumps(json.load(response), indent=2)) break except HTTPError as error: if error.code != 429 or attempt == 2: reason = error.read().decode("utf-8", errors="replace") raise RuntimeError(f"HTTP {error.code}: {reason}") from error delay = float(2 ** attempt) retry_after = error.headers.get("Retry-After") if retry_after: try: delay = max(delay, float(retry_after)) except ValueError: deadline = parsedate_to_datetime(retry_after) remaining = (deadline - datetime.now(timezone.utc)).total_seconds() delay = max(delay, remaining) error.close() time.sleep(delay)

This is a read, so retries don't create duplicate users. Its three attempts and 30-second request timeout are example client choices, not platform limits. A provider listing confirms neither account continuity nor captcha enforcement; those need end-to-end acceptance tests.

Retention changes what a failed migration can explain

Two records hide behind the phrase authentication data. An identity mapping answers which internal user an external identity belongs to. Attempt evidence answers what happened during a particular registration or callback. The first supports future logins; the second supports diagnosis. They deserve different lifetimes.

During migration validation, look for specific failure modes: state mismatch, a callback exchange that never reaches session creation, identity resolution leading to a duplicate user, and a valid session attached to a user without the intended property access. These are design cases to test, not observed provider incidents. Record the stage reached without turning authorization codes, access tokens, or session credentials into a permanent diagnostic archive. OWASP's authentication guidance is a useful starting point for reviewing the surrounding controls.

A successful test login proves less than it appears to. It establishes that one identity completed one path; it doesn't establish that a returning resident keeps the same internal account, a rejected registration creates no durable user, or a session respects the property authorization boundary. Exercise those cases before making the new path normal.

Then shorten the evidence window deliberately. Keep mappings needed for active accounts, but stop keeping raw callback material and unneeded attempt detail indefinitely. The cost is real: after expiry, an older complaint may no longer be reconstructable at the individual-attempt level. Diagnosis must rely on the remaining mapping and whatever non-secret summary evidence the retention policy preserves. Accept that loss explicitly. A smaller record is useful only when the team understands which recovery questions it can no longer answer.

Further reading

References: