I’m experiencing an issue with the Strava OAuth mobile authorization flow.
I have a system that automatically updates each Strava activity’s description with a URL to my platform: https://pacerai.vn/. When users click this link inside the Strava activity description (in the mobile app), they are taken to my website. After that, they tap the “Login with Strava” button, which redirects to:
https://www.strava.com/oauth/mobile/authorize
Problem: When users come from a Strava activity description → open my link → tap “Login with Strava”, the redirect to Strava’s OAuth page does not work.
However, if users manually open Safari → type in https://pacerai.vn/ → tap “Login with Strava”, then the redirect to https://www.strava.com/oauth/mobile/authorize works normally.
This means the issue only happens when the initial page is opened from a Strava activity description link.
I’m not sure what the root cause is (possible app webview restriction?), so any help or clarification would be greatly appreciated.
Thank you!
Best answer by Cyril
The issue is that you’re using the mobile OAuth link:
https://www.strava.com/oauth/mobile/authorize
which redirects to the Strava app, but the Strava app is busy displaying the in-app browser rendering your webpage. So the user never gets to the authorization page. Ideally, Strava would close the in-app browser and then present the API authorization page, but then your website’s user session would no longer exist.
I can see 3 solutions to this:
(ideally for all) Strava stops using in-app browsers altogether. There’s no good reason to use them in the first place, and in-app browsers present security and privacy risks for users (https://open-web-advocacy.org/blog/in-app-browsers-the-worst-erosion-of-user-choice-you-havent-heard-of/).That would be the nice thing to do, but Strava might not be keen on letting users leave their app because that might reduce their users’ interaction time...
You use the non-mobile OAuth link:
https://www.strava.com/oauth/authorize
Your users will then have to re-login to Strava within the Strava in-app browser itself. Highly confusing for users because as far as they’re concerned, they’re already in the Strava app… So not a great user experience, but if your users are keen enough they will get there. With this approach you will then encounter another fun issue: many users are unaware that they have a duplicate empty Strava account so they’ll complain that your app isn’t picking up their activities. Typically they initially signed up to Strava with a personal email address and one day they just hit the Sign in with Google / Apple / Facebook button...
You tell the users to close the in-app browser and access your app directly from a browser. Again, they must close the in-app browser at that point, otherwise the OAuth process will still fail because the Strava app will return the user to the in-app browser rather than the authorization page.
The issue is that you’re using the mobile OAuth link:
https://www.strava.com/oauth/mobile/authorize
which redirects to the Strava app, but the Strava app is busy displaying the in-app browser rendering your webpage. So the user never gets to the authorization page. Ideally, Strava would close the in-app browser and then present the API authorization page, but then your website’s user session would no longer exist.
I can see 3 solutions to this:
(ideally for all) Strava stops using in-app browsers altogether. There’s no good reason to use them in the first place, and in-app browsers present security and privacy risks for users (https://open-web-advocacy.org/blog/in-app-browsers-the-worst-erosion-of-user-choice-you-havent-heard-of/).That would be the nice thing to do, but Strava might not be keen on letting users leave their app because that might reduce their users’ interaction time...
You use the non-mobile OAuth link:
https://www.strava.com/oauth/authorize
Your users will then have to re-login to Strava within the Strava in-app browser itself. Highly confusing for users because as far as they’re concerned, they’re already in the Strava app… So not a great user experience, but if your users are keen enough they will get there. With this approach you will then encounter another fun issue: many users are unaware that they have a duplicate empty Strava account so they’ll complain that your app isn’t picking up their activities. Typically they initially signed up to Strava with a personal email address and one day they just hit the Sign in with Google / Apple / Facebook button...
You tell the users to close the in-app browser and access your app directly from a browser. Again, they must close the in-app browser at that point, otherwise the OAuth process will still fail because the Strava app will return the user to the in-app browser rather than the authorization page.
