0

I'm building an iOS app for a company whose website currently makes use of an embedded webpage for login/account creation. This embedded webpage handles some cryptographic logic that is complex to replicate. On the web, they restrict what external webpages can load the embedded webpage by checking the origin, so that only whitelisted domains can load it (e.g. third party company's webpages).

Ultimately they want to make a native version of this login for mobile, but for v1 are considering just embedding the webpage to avoid rushing the API/client side encryption. But they would need the same ability to restrict where it can be embedded.

Is it possible to get the bundle id/app id of the mobile app requesting the page, in a way that can't be modified programmatically e.g. I can't just add a header, because any app could just add the same header. I'm also looking to avoid hardcoding any credentials in the source code.

Youtube has a similar functionality to what i'm looking for, giving the option to restrict video embedding by bundle id. But says its currently not available to iOS apps: https://support.google.com/youtube/answer/6301625?hl=en

However tools like google's OAuth dashboard, require inputting the iOS apps bundle id when setting up an app. Which makes me think it is possible. But experimenting with Charles proxy and WKWebView or SFSafariViewController didn't result in it being sent up by the system. Is there anyway for a website, either through initial load or redirects etc, to get the bundle-id in a safe way?

Simon McLoughlin
  • 8,293
  • 5
  • 32
  • 56
  • 1
    https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server – Paulw11 Jul 05 '21 at 12:14
  • @Paulw11 Thanks. Right so its a lot more complicated than on the web. Theres no way to check something like the origin. We'd have to build a custom handshake around this DeviceCheck and block the content based on that. In the companies setup we'd only need to use that once for setting up the account, as a lot of the rest is public content. Probably better off just prioritising the native login now rather than putting in the effort of building an almost native login and stripping it out later – Simon McLoughlin Jul 05 '21 at 13:52
  • 1
    You can't just send a simple value because that can be spoofed. By the way, you can't trust the origin header on the web either. Someone who wanted to use your embedded login form could use their server to proxy requests to your server and simply set the origin header as they did. See https://stackoverflow.com/a/32767920/3418066 – Paulw11 Jul 05 '21 at 21:06

0 Answers0