Social sign-in boundaries

Customer App can present Apple, Google, or Facebook as an external account choice when the current build, platform, and project support that provider. Provider authorization is not a Customer App session: Ordering must verify the provider assertion, resolve the correct application account, apply any explicit link or collision policy, settle an authorized guest merge, and only then issue the Ordering session.

Current contract status

Social sign-in remains source-reviewed and pre-action. Do not use a live provider account to verify documentation. Account linking, guest merge, session issuance, provider revocation, and logout remain blocked until the current identity contract passes isolated security and lifecycle review.

Separate the responsible layers

Layer	Responsibility	What it does not prove
Customer App	Presents an eligible provider choice, opens provider UI after an explicit action, sends an opaque authorization result to Ordering, and displays local pending/error state.	Provider authenticity, account ownership, safe account linking, guest merge, or durable session creation.
Operating system	Presents native account or browser authorization when the platform supports it and returns control to the app.	That the callback belongs to the current project, account attempt, or app session.
Identity provider	Authenticates its account and returns a bounded assertion or authorization result.	The corresponding Ordering account or role.
Ordering services	Verify the assertion, resolve a namespaced provider identity, apply collision/link policy, authorize guest merge, and issue the Customer App session.	Native callback configuration or provider availability.
Session owner	Persists the returned Ordering session, applies verification/profile gates, and coordinates logout, revocation, and account switching.	Provider logout or provider-account revocation unless explicitly coordinated.
Deployment owner	Aligns the approved provider application, native callback registration, build variant, project, and server verification policy.	Runtime success from a visible button or source dependency.

Current provider choices

Choice	Current Customer App presentation	Platform boundary
Apple	Conditional sign-in choice in Login and Sign up.	The pinned Customer App source presents this choice on iOS only. Android support is not established.
Google	Conditional sign-in choice in Login and Sign up.	iOS and Android use different platform configuration and availability checks.
Facebook	Conditional sign-in choice in Login and Sign up.	iOS and Android require matching native/provider configuration. Native SDK presence does not prove the choice is enabled.

A missing choice can mean that the release, platform, project, provider configuration, or current screen does not support it. It does not identify a provider outage or a problem with the customer's external account.

Follow the identity phases

Phase	Required result	Failure disposition
1. Present choice	The current build and project intentionally expose the provider on this platform.	Keep the choice unavailable; do not infer or expose configuration values.
2. Provider authorization	The customer explicitly chooses the provider and the provider returns one bounded assertion for this attempt.	Cancellation makes no Customer App account or session change.
3. Ordering verification	Ordering verifies provider authenticity, intended app audience, freshness, and replay protection.	Reject generically; do not trust provider profile fields as proof.
4. Identity resolution	Ordering finds one exact namespaced provider identity or proposes an explicit, authorized recovery/link action.	Do not link accounts merely because email addresses match.
5. Collision or link decision	An already-linked, conflicting, disabled, privileged, or ambiguous account follows a deliberate policy.	Stop before merge/session issuance and preserve both accounts.
6. Guest merge	An authorized one-time guest claim is transactionally merged into the resolved account.	Keep guest and account state recoverable; do not partially transfer carts, addresses, orders, or installations.
7. Ordering session	Ordering issues one current session and the App durably stores it before navigation.	Remain signed out or guest; do not navigate on an unsettled session.
8. App gates	Verification, profile completion, address, project, and destination gates run for the new session.	Provider success does not bypass Customer App prerequisites.
9. Teardown	Logout, unlink, revocation, withdrawal, and account/project switch invalidate the applicable App and provider state.	Reject late callbacks and stale provider identity.

Keep linking explicit

A provider account and an Ordering account are different identity namespaces. The approved service contract should use the provider, issuer, and provider subject together. Do not use email, display name, photo, phone number, or an unnamespaced identifier as the sole account-link key.

If a provider assertion could resolve to an existing account, require the approved recovery or recent-authentication policy. Privileged or operational roles must never be implicitly linked from a matching external profile.

Public Customer App documentation does not offer a link/unlink procedure until that product flow and its recovery states are independently accepted.

Protect guest conversion

Starting social sign-in from a guest-capable screen can cross two separate boundaries:

authenticate and resolve the external/Ordering identity; and
transfer only the guest state that the current account is authorized to own.

Use an audience-bound, one-time guest claim. Rotate the guest credential, session, installation binding, and any provider identity as one recoverable transaction. A provider result must not by itself move carts, addresses, orders, payment context, messages, or notification installations.

Handle cancellation, errors, and revocation

Observable result	Safe interpretation	Next owner
Provider choice is absent	Availability is unresolved for this build/platform/project.	Release and configuration owners.
Provider UI is cancelled	No external assertion was accepted for this attempt.	App returns to the unchanged Login or Sign up state.
Provider UI returns no usable assertion	Authorization is incomplete.	Provider integration owner; no Ordering session.
Ordering rejects the assertion	Authenticity, audience, replay, account, or policy validation failed.	Identity/API security owner; show a generic error.
An account collision is detected	The provider identity cannot be safely resolved automatically.	Explicit account recovery/link owner.
Guest merge fails after identity verification	Authentication and data migration have different outcomes.	Guest/session transaction owner; do not issue a partially settled session.
Session persistence fails	Ordering may have returned a result but the App session is not durable.	Session owner; do not navigate or repeat provider authorization automatically.
Provider credential is later revoked	Provider authorization changed after App session issuance.	Revocation policy owner; do not assume one logout revokes the other.
Account or project changes during callback	The callback belongs to a stale lifecycle generation.	Reject and clear it.

Verify with providers disabled

An approved documentation fixture replaces every provider SDK and Ordering auth exchange before the screen mounts. It must cover:

choice hidden and visible by platform/build/project;
pre-action, cancel, unavailable, missing-assertion, and generic-error states;
one accepted opaque assertion without logging its value;
wrong audience, issuer, nonce/state, expired, replayed, and duplicate results;
new identity, existing identity, collision, disabled account, and privileged account denial;
signed-out and guest starts, guest-merge rollback, and session-persistence failure;
verification/profile/address gates after session issuance;
logout, provider revocation, account/project switch, and late callback denial;
accessible button, loading, error, and focus behavior on iOS and Android; and
zero provider, account, session, guest, notification, storage, or product effect outside the exact local recorder.

Provider availability and real account authorization require a separate, explicitly approved integration environment. They are not documentation proof.

Security and privacy rules

Never log or publish provider assertions, authorization codes, profile payloads, client or application identifiers, callback values, Ordering sessions, guest claims, or notification installation tokens.
Send only the minimum provider data needed for server verification and the approved account experience.
Bind every callback to the initiating build, project, provider, attempt, account/session generation, and expected redirect state.
Make identity creation/linking, guest merge, session issuance, installation reassignment, plugin work, and audit history transactional or recoverable.
Use generic public errors that do not disclose whether an email, provider subject, privileged role, or Customer App account exists.
Treat provider logout, Customer App logout, unlink, revocation, and account deletion as separate actions with an explicit coordination policy.

Revalidate when the contract changes

Repeat the isolated review after changes to provider SDKs, native schemes or entitlements, public availability gates, server verification, identity-linking rules, guest merge, session storage, notification installation assignment, verification/profile gates, logout/revocation, or privacy/retention policy.

Separate the responsible layers​

Current provider choices​

Follow the identity phases​

Keep linking explicit​

Protect guest conversion​

Handle cancellation, errors, and revocation​

Verify with providers disabled​

Security and privacy rules​

Revalidate when the contract changes​