UnsupportedOperationException: This isn't a hierarchical URI about appauth-android HOT 5 CLOSED

We may be able to add support for this special URI, but we currently recommend either using a custom scheme reflecting your package name or an HTTPS app link. I'm on vacation right now, I'll comment further when I get back next week.

from appauth-android.

Unfortunately urn:ietf:wg:oauth:2.0:oob implies the use of WebView, as it's a redirect URI that embeds the authorization code in a HTML page which the app can then inspect. Apps being able to inspect and interact with the content of the page is one reason why AppAuth doesn't support WebView (and one reason why Google recently deprecated the use of OAuth in WebView).

Until this Authorization Server supports custom URI schemes, as a workaround you can potentially redirect to a page on your website, which can then 302 Redirect to your custom scheme. Iain has a demo of this workaround.

from appauth-android.

I don't see how the URI urn:ietf:wg:oauth:2.0:oob implies the use of WebView. I'm familiar with the Google post that you mention, but I don't see how that applies here.

Developers just have to declare the scheme in their app manifest, just as you describe in your ReadMe:

<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="urn"/>
</intent-filter>

No WebView required.

I successfully ran a small POC in my fork with the sample provided in this repo.

Am I missing something?

from appauth-android.

So is this Authorization Server passing the authorization code as a param on the oob URI? That's a little different how Google treats the same (deprecated) oob redirect where the authorization code is part of the HTML page (and requires extraction). So perhaps in this case oob doesn't require WebView but it was certainly was still designed for WebView.

oob isn't well suited to browser-based OAuth, there's a better and more standard way to do this which is custom URI schemes & claimed-HTTPS redirects. One issue I see with your implementation is that you've claimed urn globally which means that your app will be competing with all apps that use this redirect choice to get the return intent (as a side point, can you at least claim only urn:ietf:wg:oauth:2.0:oob so you're not getting non-OAuth related intents as well?). It may work OK in Chrome Custom Tab which preferences the app that launched it for the redirect intent, but if the request was launched in a different browser, then all apps claiming this scheme would compete for the authorization response's redirect intent which would confuse the user (at best).

Since supporting the older WebView OAuth patterns is a non-goal for AppAuth, I don't see us supporting this redirect option in the main repo.

from appauth-android.

Yes, the authorization code is passed as a param on oob.

Thanks for the feedback on the POC. I'd definitely use a specific path along with the urn scheme in production code.

Not supporting old patterns sounds reasonable. I appreciate the explanation and will look for alternatives.

from appauth-android.