Post

Replies

Boosts

Views

Activity

ASWebAuthenticationSession + bearer token callback in Capacitor app — acceptable without 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 ASWebAuthenticationSession receives 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: ASWebAuthenticationSession materially 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
0
0
34
12h
ASWebAuthenticationSession + bearer token callback in Capacitor app — acceptable without 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 ASWebAuthenticationSession receives 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: ASWebAuthenticationSession materially 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
Replies
0
Boosts
0
Views
34
Activity
12h