Add Authentication Provider

A user links an additional sign-in method to their existing account.

Planned — not yet live.

Who Can Do This

Any user with status: active.

Providers

Three authentication providers are available:

Provider Used for regular sign-in Used for account recovery Platform
Google ✓ ✓ iOS, Android
Apple ✓ ✓ iOS only
Mobile/OTP ✗ ✓ iOS, Android

Mobile/OTP is the recovery provider. It cannot be used on the regular sign-in screen. It is only usable on the account recovery page (/recover) — see Account Recovery below.

Adding a Provider from Profile Settings

  1. Go to account settings in the app.
  2. Select a provider to add (only providers not already linked are shown).
  3. Complete the linking flow for that provider:
  4. Google — complete Google Sign-In.
  5. Apple — complete Apple Sign-In (iOS only).
  6. Mobile/OTP — enter a phone number and verify it with a one-time code.
  7. The provider is linked to the existing account immediately.

Rules

  • Linking a provider does not create a new account — it adds a sign-in method to the existing one.
  • Apple Sign-In can only be initiated on iOS.
  • Google Sign-In is available on both iOS and Android.
  • The app only shows providers not already linked.
  • A user cannot remove their only linked sign-in provider (Google or Apple). Mobile/OTP alone is not sufficient to sign in — at least one of Google or Apple must remain linked.
  • Apple-only users on Android: a user who signed in with Apple only and has not linked Google cannot sign in on Android. To avoid this, link Google from an iOS device before switching platforms.
  • The phone number linked via Mobile/OTP is shown in profile settings and cannot be changed directly — to change it, the user must update the Mobile/OTP provider through this flow.
  • The navigation screen is a locked screen — adding a provider is not accessible on a device with an active ride in progress. The user must end the ride first. This is device-specific: the user can add a provider from a different device while a ride is active on another.

What Happens Next

The newly linked provider is available immediately. For Google and Apple, the user can sign in with that provider on any supported device. For Mobile/OTP, the number is registered as the recovery phone.

Failure Cases

  • Provider already linked to a different account: Firebase Authentication detects the conflict. Because the user is already signed in, the prompt asks whether to link the conflicting provider to the current account (merging both providers onto one account) or cancel and leave the provider unlinked. This differs from the sign-in conflict described in Sign In, where the user is not yet signed in and can choose which account to continue with.
  • Provider already linked to a banned account: the ban persists after linking — same account, same status.
  • Provider already linked to a to-be-deleted account: the user is informed the account is pending deletion and offered the option to cancel deletion.
  • Invalid phone number (Mobile/OTP): if the number is missing a country code or contains non-digit characters, the user is prompted to re-enter it in the correct format (e.g. +919876543210) before the OTP is sent.
  • OTP not received (Mobile/OTP): the user can request a new code. If the number was mistyped, they can re-enter it and restart the OTP flow.
  • OTP expired (Mobile/OTP): codes expire after a short window. The user can request a new one.
  • Authentication error: if linking fails and cannot be resumed, the user is informed and the provider remains unlinked.

Remove Authentication Provider

A user removes a linked sign-in method from their account.

Planned — not yet live.

Who Can Do This

Any user with status: active who has at least one Google or Apple provider remaining after removal. Mobile/OTP cannot be the sole provider.

Steps

  1. Go to account settings in the app.
  2. Select the linked provider to remove.
  3. Confirm removal.

Rules

  • At least one of Google or Apple must remain linked after removal. The user cannot remove a provider if doing so would leave them with only Mobile/OTP or no providers.
  • Before removal, the app warns if removing the provider would leave the user unable to sign in on a specific platform (e.g. removing Google means no Android sign-in; removing Apple means no Apple-initiated sign-in on iOS).
  • Removing Mobile/OTP clears the recovery phone number from the account and from profile settings.
  • Once removed, a provider can be re-linked at any time.
  • The navigation screen is a locked screen — removing a provider is not accessible on a device with an active ride in progress. This is device-specific: the user can remove a provider from a different device while a ride is active on another.

What Happens Next

The removed provider can no longer be used. For Mobile/OTP, the recovery phone is cleared.

Failure Cases

  • Only sign-in provider remaining: Google or Apple cannot be removed if it is the last one. The user must link another Google or Apple provider first.
  • Authentication error: if removal fails, the provider remains linked.

Account Merge Detection

Planned — not yet live.

Two signals can reveal that two separate 95octane accounts belong to the same person. When either is detected, the app offers to merge the accounts into one.

Signal 1 — Shared Mobile/OTP Phone Number

If a user signs in with a new provider (e.g. Apple) and creates a new account, but the phone number they have linked via Mobile/OTP is already registered on an existing account, Firebase Authentication detects the credential conflict. The app uses this to surface a merge prompt: "We found another account linked to this phone number. Would you like to merge them?"

Signal 2 — Subscription Restoration

When a user restores a previous subscription (e.g. after reinstalling the app or signing in on a new device), RevenueCat returns the originalAppUserId from when the subscription was first purchased. If this does not match the current user's account, it indicates the subscription belongs to a different account. The app uses this to surface a merge prompt: "This subscription was purchased on a different account. Would you like to merge them?"

Merge Flow

When either signal is detected:

  1. The app shows a prompt identifying the two accounts and asking the user to confirm the merge.
  2. The user confirms. All auth providers from both accounts are consolidated into one account using Firebase's linkWithCredential. All data — buddies, favorites, ride history, and pending buddy requests (sent and received) — is merged into the surviving account.
  3. The now-redundant account is deleted. The user is signed into the merged account.

Rules

  • Merging is always user-confirmed — the app never merges silently.
  • Merging is blocked if either account is banned, banned_final, or to_be_deleted. When a merge signal is detected and either account is in one of these states, the merge prompt is suppressed — no offer is shown and the signal is ignored. This prevents using a merge to escape a ban or circumvent a pending deletion.
  • When both accounts have active subscriptions: the app asks the user to select which subscription to retain before confirming the merge. The redundant subscription is not cancelled automatically — the user must cancel it manually via the App Store or Google Play after the merge completes. The app shows manual cancellation instructions at this point.
  • If the user declines the merge: for Signal 2 (subscription restoration), the subscription is transferred to the current account via RevenueCat regardless of the merge decision — the two accounts remain separate. For Signal 1 (shared phone number), declining keeps both accounts and both subscriptions unchanged.
  • Merging is not reversible. Once confirmed, the redundant account is permanently deleted.
  • Merge during onboarding: Two signals can fire during onboarding:
  • Signal 2 (subscription restoration) is checked automatically at the start of onboarding — see Onboarding. If confirmed, the onboarding account is the redundant one — it is discarded and the user is signed into the surviving account.
  • Signal 1 (shared phone number) is checked after the OTP is verified in the recovery phone step — see Onboarding. The merge prompt appears before the user advances to the next step. If confirmed, the onboarding account is discarded. If declined, both accounts remain separate and onboarding continues with the phone number linked.
  • There is no concept of a "primary" account — both accounts belong to the same person and all data is combined.
  • When profile fields conflict (city, name, photo, notification preferences, location sharing), the older account's values win. "Older" means the account with the earlier creation timestamp.
  • User-verified emails: all user-verified emails from both accounts are combined into the merged account's email list. Duplicate addresses (same address on both accounts) are deduplicated. All resulting emails receive product communications and can be removed individually from profile settings, as long as at least one remains.
  • Buddy caps (the 3-request lifetime cap and the removal-cap-of-0) carry forward as the most restrictive of both accounts. If either account had a cap of 0 to a given user, the merged account retains that 0.
  • Premium-ride quota: the merged account's consumed quota is the sum of both accounts' consumed slots. Remaining quota = max(0, 4 − combined consumed). If the two accounts have consumed 4 or more starts in total, the merged account has 0 remaining quota and rides at Essential tier.
  • Self-buddy after merge: if the two merging accounts are mutual buddies with each other, the resulting self-buddy relationship is silently removed. No notification is sent.
  • Shared buddy after merge: if both accounts have a buddy connection with the same third-party user, the duplicate is silently deduplicated into a single connection on the merged account. No notification is sent.
  • This mechanism also addresses the buddy cap reset abuse vector: if a user deletes their account and recreates it but links the same phone number, the system detects the phone credential conflict and can surface the prior account's history.

Account Recovery

A user who has lost access to their Google or Apple account can recover their 95octane account using Mobile/OTP.

Planned — not yet live.

Who Can Do This

Any user who has previously linked a Mobile/OTP provider to their account.

Steps

  1. Navigate to the account recovery page (/recover) — this page is separate from the regular sign-in screen and is not prominently linked from it.
  2. Authenticate using Mobile/OTP: enter the registered phone number and verify with a one-time code.
  3. Once verified, the user selects the provider to replace (Google or Apple) and completes authentication with the new account for that provider. The new sign-in must succeed — if it fails, the recovery is not applied.
  4. The old provider is explicitly removed from Firebase Authentication and replaced by the new one. Only one provider per type is allowed. If the Firebase removal fails, the entire recovery fails and the user is prompted to retry.
  5. The user returns to the regular sign-in screen and signs in with the newly linked provider.

Rules

  • The recovery page only allows replacing an auth provider. One provider slot per type is enforced — a user cannot have two Google or two Apple accounts linked simultaneously.
  • The user must successfully authenticate with the new provider before the replacement takes effect. If authentication fails, the old provider remains.
  • After completing recovery, the user must sign in normally via Google or Apple. The recovery page does not grant app access directly.
  • Mobile/OTP is the only provider available on /recover. Google and Apple are not accepted here — they have their own account recovery mechanisms.
  • If the user has not linked Mobile/OTP, they have no self-service recovery path. Account deletion can still be requested by contacting support.
  • Recovery is not available for banned or to_be_deleted accounts. If the phone number belongs to an account in either of these states, the recovery page shows an error and no provider changes are allowed.
  • All provider replacements via the recovery page are recorded in an audit log for fraud detection.

What Happens Next

The new provider is linked and the user can sign in normally on the sign-in screen. A security notification is sent to all email addresses on the account — specifically including the old provider's email — informing them that a sign-in method was replaced. This is the primary signal for detecting unauthorised recovery (e.g. SIM swap).

Known gap: There is currently no self-service response path for a user who receives this notification and did not initiate the recovery. The notification serves as a detection signal only — no account lock, recovery reversal, or in-app action is available. A user in this situation must contact support. A proper response flow (e.g. one-click revert link in the email) will be considered once the recovery feature is live and abuse patterns are understood.

Known limitation: If the account has no email address (e.g. an Apple "Hide My Email" user who never added a verified email), no security notification can be sent after a recovery. The SIM-swap detection signal silently fails with no fallback channel. Users are encouraged to add a verified email to their account to ensure they can be notified of provider changes.

Failure Cases

  • No Mobile/OTP linked: the user cannot use the recovery page. No self-service recovery path exists.
  • Account is banned or pending deletion: the recovery page shows an error. No provider changes are allowed.
  • OTP not received: the user can request a new code.
  • OTP expired: the user can request a new one.
  • Phone number no longer accessible: no self-service recovery path exists. The user must contact support.
  • Old provider removal fails in Firebase: the recovery is rolled back. The old provider remains linked and the user is prompted to retry.
  • New provider already linked to a different 95octane account: recovery fails with an error. The user must choose a different provider credential or contact support. No automatic resolution is available.

Known limitation: If the new provider credential the user tries to use during recovery is already linked to a different 95octane account, recovery cannot proceed. If the conflicting account belongs to the same person (e.g. a duplicate account), the user must contact support — merging accounts is not available from within the recovery flow. A possible self-service path after contacting support is to first resolve the duplicate via account merge on the surviving account, then retry recovery with a fresh credential. If the credential belongs to a different person, there is no recovery path using that provider.