Build a mobile sign-in flow with AI: session, callback and account recovery

A worked example: where the task becomes difficult

A fictional field app opens an external sign-in page but returns to the wrong app route. The developer tests only the web version, where the callback works. Identify the native scheme or link configuration and the provider’s allowed return destinations. Keep credentials out of debug output and preserve the original task, such as opening a visit, after successful authentication.

Decisions to make before implementation

Define secure session persistence appropriate to the runtime and provider. Consider account switching, revoked sessions and app restart. Validate deep-link destinations and avoid granting access based on callback parameters alone. Keep server authorization in place even when the mobile interface believes it is signed in. Decide how recovery works when the user dismisses the external sign-in flow.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Inspect the existing identity provider and native callback configuration.
• Implement explicit checking, signed-out and signed-in states.
• Verify controlled sign-in, cancellation, app restart and sign-out.
• Retest the protected resource with direct server authorization checks.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Repair or implement mobile sign-in using the existing provider and callback contract. Trace external login, native return and session establishment separately. Preserve the requested visit route and validate its scope. Include cancellation, restart and sign-out. Do not expose tokens or substitute a local boolean for server authorization.

Failure modes that an attractive preview can hide

A successful external login can still fail to establish the app session. Do not hide that state behind an infinite spinner. A local signed-in boolean is not a trusted credential. Avoid storing secrets in ordinary logs or screenshots. Simulator-only testing may miss actual external-browser and app-return behavior.

Technical references: Expo: start developing

Acceptance checks and the evidence to retain

Keep callback configuration, session-state evidence and device test results. Distinguish identity-provider success from protected-resource access in the app.

Specific answers

Common questions