Setting non standard allowed origin for mobile apps

Hi,

My topic is related with this one:

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.

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?

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

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?

@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 @bcook 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…

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 :wink:. Thanks. For the moment we’ll continue with the service as you propose.

Thanks to everyone for your support.

Best regards.

1 Like

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

Should be live in a bit!