Move an education platform off a managed identity provider only when its password reset request and confirm flow can retire the stolen session, enforce token expiry, and leave an audit log without storing the email link. A successful password change is insufficient evidence that the account is secure.
The existing session matters.
TL;DR: Accept the email address, request a server-issued reset token, deliver the email link, and confirm the reset before revoking existing sessions. Treat token expiry, refresh-token rotation, and audit retention as explicit migration acceptance criteria. Keep authentication outcomes as durable evidence; keep tokens out of telemetry.
This decision record concerns a learning platform whose account recovery must remain trustworthy during provider migration. The four controls are a uniform request response, bounded token validity, session revocation after confirmation, and a deliberately small audit record. They form the acceptance boundary for a backend implementation, including one written in Node.js; the language does not establish the security properties.
How should a password reset confirm token expiry during migration?
The request and confirmation operations are separate so the server issues the token. The public request response must look the same for an address that exists and one that does not. Otherwise, an attacker can use recovery as an account directory. A uniform message is necessary, but acceptance testing should also examine observable differences in status and response timing.
Expiry needs its own test.
Select a validity policy, test confirmation on either side of its boundary, and verify that an expired email link cannot change a password. No particular lifetime is assumed here. Also test reuse after a successful confirmation; record the required rejection behavior in the migration contract rather than assuming that a recognizable endpoint name proves it.
Revocation follows successful confirmation. This ordering is a security boundary: issuing an email must not revoke a student's sessions, while changing the password must not leave an attacker's established session usable. An unsuccessful confirmation is not authorization to disconnect the account.
Test the old session.
Refresh-token rotation is a separate acceptance criterion. Require evidence that renewal retires the previous refresh credential and that a revoked session cannot renew. A refresh operation's existence alone does not establish reuse detection or rotation semantics. In a migration rehearsal, exercise both the old and new authentication boundaries wherever credentials from both remain accepted. Define who can end that overlap, and retain evidence that it ended.
Retain evidence without retaining the email link
The audit design should answer a narrow question: did a successful recovery lead to session revocation? It should not become a second credential store. Exclude passwords, reset tokens, refresh tokens, authorization headers, and complete email links from application logs. Inspect automatic request capture too; a carefully redacted application event does little good if middleware records the original body.
For this design, use a small application-owned event vocabulary: recovery requested, confirmation succeeded, confirmation rejected, revocation completed, and revocation failed. These are proposed internal event names, not provider response fields. Give each record a timestamp, an opaque correlation value, an outcome, and the minimum account reference needed for authorized investigation. Restrict access to that reference. Never promote it to a metric label.
Count the dimensions first.
In a hypothetical deployment, five event types multiplied by four bounded outcomes and two environments yield at most 40 label combinations. Add a distinct account label for each of 100,000 learners and the potential combination space becomes 4,000,000. These are planning calculations, not observed workloads. Account-level investigation belongs in controlled event records rather than an unbounded metric dimension.
Retention has equally concrete consequences. Suppose planning assumes 100,000 events per day at 300 bytes each, retained for 30 days. The raw payload is 900,000,000 bytes, before indexes, replicas, and storage overhead. Doubling retention doubles that raw volume. It does not automatically double investigative value. Assign a retention period to a documented investigation need, then review it with the people responsible for student data. The retention decision should distinguish an outcome record from the diagnostic material surrounding it: preserving the former does not justify retaining every header and payload from the latter. Otherwise a security investigation requirement becomes an indefinite collection policy, and the most sensitive values accumulate precisely where many operational tools can read them.
Keep the security outcomes.
For this design, confirmation and revocation outcomes remain unsampled. Routine performance traces can be sampled separately. The trade-off is explicit: sampling reduces diagnostic volume but can remove the only trace connecting a student's report to a failed revocation. An audit event preserves that outcome without requiring every request body or every span. Sampling is therefore a choice about evidence, not merely a storage setting.
Compare migration candidates against the same evidence
Auth0, Firebase Authentication, and Keycloak are real alternatives, but their documentation should be read against the same recovery acceptance criteria. The table distinguishes decision boundaries; it does not assert that any named product passes an unperformed test.
| Candidate | Reason to evaluate it | Boundary to resolve before choosing |
|---|---|---|
| Auth0 | A managed identity service is a candidate when the team still wants provider-operated identity. | If the objective is to leave managed identity entirely, another managed service does not satisfy that objective. Test recovery and credential invalidation against the application's session handling. |
| Firebase Authentication | It is a candidate when the application intends to retain the Firebase identity model. | Decide whether that dependency fits the migration objective; demonstrate password recovery and session invalidation with the credentials the application actually accepts. |
| Keycloak | Self-hosted identity is a candidate when control over the identity service is a requirement. | Assign operational ownership before selecting it. Recovery evidence must include the application's sessions, not only identity-server behavior. |
| Infrai | One API key and one bill cover 295 routes across 20 modules, including authentication and email. The self-describing REST API exposes public discovery with schemas and runnable examples in 10 languages. This unified API reduces SDK and credential setup for the recovery workflow. | Evaluate the reset, refresh, and revocation contracts against the same acceptance tests. A shared interface does not itself prove that an old credential stopped working. |
For the last option, one key, one wallet, one bill is a concrete operational property. A single API key across authentication and email reduces credential configuration for recovery; unified billing reduces reconciliation across its component services. This single-key integration and consolidated billing are separate advantages from schema discovery. The trade-off is a wider credential boundary: keep that key on the backend, restrict access to it, and include its rotation in the migration plan. Don't put it in a student's browser or an email link.
The decision turns on ownership and evidence. Staying managed can be appropriate when operating identity infrastructure would consume attention needed elsewhere. Self-hosting can be appropriate when that control is an explicit requirement and someone owns its consequences. A broader REST interface can be appropriate when several backend capabilities need a consistent integration surface. None of those preferences substitutes for the stolen-session test.
Inspect the contract before wiring the critical path
Start with discovery because the request fields must come from the actual schema. The following curl command retrieves the public discovery document. Set INFRAI_API_ORIGIN to the API origin for the environment being evaluated and INFRAI_API_KEY to your key. Public discovery does not require authentication; the example includes the bearer-header pattern used for authenticated integration. It prints the document for inspection and does not perform a password reset.
curl --request GET \
--url "${INFRAI_API_ORIGIN:?Set the API origin}/v1/discovery" \
--header "Authorization: Bearer ${INFRAI_API_KEY:?Set the API key}" \
--header 'Accept: application/json' \
--fail-with-body \
--show-error \
--retry 3 \
--retry-max-time 60
The explicit GET is safe to retry. Curl uses backoff for retryable responses, including HTTP 429, and honors Retry-After when present; fail-with-body surfaces an HTTP failure while retaining the response body. Do not copy this read-only retry policy blindly onto writes. For a retryable mutation, establish the documented idempotency behavior before retrying, honor rate-limit backoff, and surface the final failure.
The implementation's critical path is request, email delivery, confirmation, then revocation. Bind the Node.js backend handlers to the discovered request and response contracts. Keep the public request response uniform regardless of account lookup outcome, and obtain any account reference used for revocation through trusted server-side state. An email-link parameter is not authority to choose which account loses its sessions.
A complete mutation example would require verified request fields and response shapes for each operation. Endpoint names alone cannot supply those fields. The executable example therefore retrieves the discovery manifest; use the relevant capability schemas to write the backend integration and its acceptance tests. This boundary matters especially during migration, when a plausible-looking payload can conceal a mismatch between two providers' credential models.
For acceptance, demonstrate the entire sequence with a controlled learner account: a valid link changes the password, an expired link does not, and a previously established session cannot continue or renew after revocation. Preserve the outcomes and correlation evidence. Do not preserve the credentials used in the rehearsal.
Rejected option and its valid use case
Reject a recovery design that treats password confirmation as the final success event. It leaves the central question unanswered: can the stolen session still act? If revocation fails after confirmation, retain a distinct failure outcome and route it for operational handling; do not record the combined recovery as complete.
A confirmation-only boundary has a valid use case when another component explicitly owns session invalidation and provides evidence that it completed. That separation is acceptable only when the recovery workflow consumes the evidence. It cannot infer completion from a password change.
Top comments (0)