Redirect is not working
MathiasGrasy opened this issue · comments
We have a redirect issue, probably related to the one already discussed in your archived repo: oktadev/okta-openidconnect-appauth-android#2
Any news, fixes or workarounds on this one? We have created two apps in the Okta system (one for development purposes and one for production). Connecting to the development app, the redirect seems to work just fine, but when we change the Okta settings inside our Android app and want to connect to the production app the redirect is failing (Logcat error: "chromium: [INFO:CONSOLE(0)] "Navigation is blocked: com.oktapreview.dev-233232:/callback?....").
We are using the same redirect url for both Okta apps, but this cannot be the reason for this issue, can it?
Hey @MathiasGrasy! Sorry for the delay.
If you use two different private URI schemes (com.oktapreview.dev...), does your app redirect as intended?
@jmelberg-okta thanks for you answer.
Actually we tried to use other schemes already, didn't fix the issue. We tested again connecting to our development app and production app and it seems to work on neither of them (unfortunately I was wrong before in supposing it's working for our development app.)
If I trigger the redirect url via adb (without the use of any browser), the app opens as intended: adb shell am start -a android.intent.action.VIEW -d "com.oktapreview.dev-233232:/callback". So I suppose our scheme is set up correctly.
We've found a possibility to whitelist specific browsers inside the AuthorizationService, and if only the Firefox browser is whitelisted, the redirection works. So it really seems to be a chromium security topic in combination with javascript.
We've found a few discussions about it:
https://stackoverflow.com/questions/41524087/navigation-is-blocked-when-redirecting-from-chrome-custom-tab-to-android-app
https://stackoverflow.com/questions/45681456/chrome-custom-tabs-initial-okta-auth-not-redirecting-back
EddyVerbruggen/Custom-URL-scheme#156
Any chance, that we maybe set up something wrong or there's any hotfit for this?
I also fall into this issue. Is there any tempo solution to fix this?
@gloryluu,
As @MathiasGrasy mentioned, this is unfortunately a known problem with Chrome Custom Tabs and how it handles JavaScript initiated redirects.
The lead maintainer of AppAuth proposes the following:
Create a web page for your redirect URI that displays an interstitial page with a Click here to return to app button. Ian McGinniss (AppAuth-Android Author)
There is a working sample application referenced here, where the interstitial page is used to capture the code and state values from the callback. Then, redirect the user back to the private-use URI scheme specified by your application.
The flow should look similar to:
Mobile App > Redirect to Okta for authentication > Redirect to Interstitial > Redirect to Mobile App
To provide more detail, Chrome is evaluating a read-only property called event.isTrusted to determine whether or not to permit the redirect. When a user is redirected to Okta, the Okta Sign-in Widget performs the authentication flow, prompting for MFA (if enabled), and/or user lifecycle operations (password reset). In many cases, the Widget is initiating JavaScript redirects, which result in a false isTrusted property.
I'm working closely with our internal teams to find a better solution for this - so I apologize that I cannot provide a "fix" right away. In the meantime, I'd suggest implementing the workaround described above.
Another workaround that seems to work is to force the User Consent page to appear (the consent feature is in Early Access, so you'll have to contact support to enable it).
Then by setting prompt=consent when logging in and requesting a scope which requires consent you can force the consent page to appear. The redirect works after clicking "Allow Access".
Any updates on this issue? Is there a better solution than the the interstitial page?
@janvde, we're seeing hope on this known issue from the Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=738724#c17
Looks like a fix might be coming in the January time frame.
In addition to the fix possibly coming through the Chromium team, we are investigating a fix on our end. Sorry for the long delay on this, it was a really tough bug to reproduce.
Hi, I'm facing the same problem when my Custom Tabs blocks my callback from the Okta authentication page. Do you have any updates on this by any chance or should we wait for the fix by the Chromium team and do the workaround with the interstitial page as mention @jmelberg-okta?
Update on this: we have identified a fix and are planning to start rolling it out in the next month or so. The fix will not require any updates to Android apps using this SDK, it will "just work" because we are fixing things in our sign-in page. We will be rolling this out slowly. If you have an urgent need to test it, send me an email at nate.barbettini@okta.com.
It is likely that Chrome 72 will fix the issue as well, but we are still moving forward with the fix on our side because not everyone will have Chrome 72 right away (or ever, depending on the device and update policy).
@nbarbettini Hi Nate, any update yet? Running into this issue at multiple customers and would like to see this fixed. Now we have to host a custom interstitual page to solve this issue.
I have a more or less similar problem. I have to connect my app to a Keycloak instance using appauth, and I've tried many suggestions of stackoverflow, but none of them has worked for me. Seems like my keycloak instance doesn't find my app address to send the authentication data.
I have a more or less similar problem. I have to connect my app to a Keycloak instance using appauth, and I've tried many suggestions of stackoverflow, but none of them has worked for me. Seems like my keycloak instance doesn't find my app address to send the authentication data.
Update: I've resolved my problem. I realize I forgot to set the ":/oauth2redirect" in m keycloak instance.
@Robingaal et al: We are in the process of rolling out the fix. We can enable it early on a per-org basis if you email support@okta.com with this information: your org URL, whether you are using the Custom Sign-in Page feature (which requires Custom URL Domain). And be sure to reference this thread!
Thanks for your patience. I've replied to the folks who emailed me directly re: the above message - if not, feel free to ping me again. Sorry for the delayed responses!
So far Im stucking with the issue, so I tried to follow the interstitial page solution to fix it completely but I cannot redirect to the interstitial page after successfully login. It just stay there as nothing happen:
Dont know if I was missing anything. Here are my steps:
1/ Define the interstitial url as redirect uri in Okta portal: https://my_interstitial_page.com/oauth2redirect
2/ In okta_app_auth_config.json, define redirect_uri as https://my_interstitial_page.com/oauth2redirect
3/ In Manifest, let the RedirectUriReceiverActivity to handle the interstitial one:
<activity android:name="net.openid.appauth.RedirectUriReceiverActivity" android:exported="true" tools:node="replace"> <intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="mycustom_scheme"/> </intent-filter> <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="https" android:host="my_interstitial_page.com" android:path="/oauth2redirect"/> </intent-filter> </activity>
Guy, did I missing anything ? I read the sample of Ian many many time but cannot stiill figure it out. So anyone can help me out I'm really appreciate 👍
@nbarbettini could you share technical details about the fix? is it available in a branch somewhere? The custom tabs redirect problem affects more than Okta and your comment is the first mention of a workaround I could find anywhere.
@Robingaal et al: We are in the process of rolling out the fix. We can enable it early on a per-org basis if you email support@okta.com with this information: your org URL, whether you are using the Custom Sign-in Page feature (which requires Custom URL Domain). And be sure to reference this thread!
Thanks for your patience. I've replied to the folks who emailed me directly re: the above message - if not, feel free to ping me again. Sorry for the delayed responses!
The fix is deployed for all orgs. No need to send @nbarbettini emails.
@FeiChen-okta can you share more details about the mentioned fix? Thanks.
@tasomaniac I don't know the details as the workaround is not in the SDK.
Can you help us find a link to the mentioned fix that was deployed for all orgs?