Setting non standard allowed origin for mobile apps

[supakonoha]

Hi,

My topic is related with this one:

Setting non standard allowed origin

Hello! I’m developing mobile app with react-native and Trello API and kind of stuck with authentication. I’m using webview to send user to https://api.trello.com/1/authorize and a small device hosted web page with a script to grab returned token and pass it to the app. Hosted page can have very weird return urls like about:blank or file:///android_asset/auth.html which I cant set at https://trello.com/app-key allowed origins list. Just putting * doesn’t seems to work either (although pages st…

We’re developing a mobile application using Trello API and we’re implementing authentication on the app. We are trying to redirect to our app scheme for the return url but we cannot specify on Allowed Origins something like app://return_url at https://trello.com/app-key, where app is the scheme registered on the system for our app.

I think it’s similar to the previous topic, but I would like to know if you are going to allow custom origin schemes on Trello API.

Thanks in advance and Best Regards.

[bentley]

We don’t currently support non-http-based URLs for allowed origins.

Is there a standard URL format that would be used here that we could include in a regex? Is app:// used elsewhere?

@selim13 do you have thoughts?

[supakonoha]

You can check Apple documentation. Android is similar:

https://developer.apple.com/documentation/uikit/inter-process_communication/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app

[selim13]

I don’t think there any standard URL format for locally hosted webpages.

Those I’ve met were about:blank for react native’s webview displaying inline html and file:///android_asset/auth.html for displaying internally hosted file. And they are different for IPhones.

But all of those can be covered by standard URL sanitization. Is there really a need for any other checks?

[dmehers]

@supakonoha … Doing OAUTH in the app may not be such a good idea, you may want to consider doing it via a web service.

You might not be able to get away with doing it entirely in the app because you’ll need to embed the OAUTH 1 application Secret in the app where it will be vulnerable to decompiling …

For my apps I use a simple AWS lambda via AWS API Gateway that does the OAUTH dance and then my lambda redirects to the app-specific URL… The secret is held by this lambda and is never exposed.

@selim13 @bentley Unless I’m missing something (which is entirely possible!), you may want to think twice before allowing non-https redirects since it might encourage people to embed the OAUTH1 secret in an app, which is a massive vulnerability…

[supakonoha]

Hi,

Thanks @dmehers. Yes that’s the solution we’ve implemented. And yes, it’s a risk to have the secret on the app. For the moment we have an iOS app and we have some secrets on the app, but never on the code . Thanks. For the moment we’ll continue with the service as you propose.

Thanks to everyone for your support.

Best regards.

[bentley]

We’ve implemented allowing custom schemes for URLs: Allow any URL scheme for Allowed Origins.

Should be live in a bit!