We’re trying to determine whether an iOS authentication flow is safe for production when ASWebAuthenticationSession ultimately returns a reusable backend bearer token because the authentication provider does not support a native authorization-code/PKCE exchange.
We have an iOS app built with React + Capacitor that uses @capgo/capacitor-inappbrowser for Apple/Google social login.
The iOS flow uses ASWebAuthenticationSession.
Our backend/auth provider is Base44. Base44 supports web OAuth, but they have confirmed they do not provide a supported native authorization-code / PKCE session exchange for externally wrapped Capacitor apps.
Current flow:
- The app starts Base44 OAuth in
ASWebAuthenticationSession. - Base44 completes Apple or Google authentication.
- Base44 redirects to an HTTPS bridge page hosted on our Base44 app domain.
- The bridge receives the Base44 access token.
- The bridge redirects to our app callback URL scheme and includes that Base44 bearer token in the callback.
- The active
ASWebAuthenticationSessionreceives the callback. - The app validates the callback URL, verifies a one-time random state, sets the Base44 token and immediately calls
auth.me()to confirm the authenticated account.
We have already hardened the flow by:
- using a 256-bit random one-time state
- expiring pending login attempts after 10 minutes
- binding the state to the provider and locally stored return path
- validating callback scheme/host/path
- removing unsolicited/global deep-link authentication listeners
- using
prefersEphemeralWebBrowserSession = true - scrubbing token artifacts from the hosted bridge URL/local storage
- not trusting callback-supplied return paths
- verifying the Base44 account before marking native login complete
We understand that the preferred native OAuth model is authorization code + PKCE, but the backend provider does not expose that capability for this integration.
My question is:
Given that ASWebAuthenticationSession delivers the authentication callback to the initiating session, is passing a reusable backend bearer token through that callback still considered unsuitable for a production iOS app?
If it is unsuitable, is there any secure pattern available when the authentication provider does not support a native one-time code / PKCE exchange?
We also need to preserve existing Apple/Google-linked Base44 accounts, user data and subscription entitlements, so replacing the authentication backend is not a simple migration.
I would particularly appreciate guidance on whether:
ASWebAuthenticationSessionmaterially mitigates custom-scheme interception in this scenario- changing to a Universal Link callback would materially improve the design if the bearer token still has to be transferred
- this architecture would be considered acceptable for an App Store production release