I'm implementing Dropbox API for a certain second tier mobile platform. The user needs to log on to Dropbox via their Web interface; I create a web view and make it navigate to https://www.dropbox.com/1/oauth/authorize, as per the docs. The UI looks like a desktop Web page - with lots of pictorial fluff and hopelessly zoomed out.
On the other hand, on iOS and Android the logon page looks perfectly mobile friendly.
Question - is there a way to explicitly invoke the mobile logon page, the way iOS and Android API's do? An alternative URL, a custom header, a User-Agent string?
My browser control is WebKit-derived - it should understand things like CSS media queries and <meta viewport>. But it looks like there aren't any.
You can add ?display=mobile to force the mobile version.
Related
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?
I have native iOS app and one of the flows of the app should be done with WebView. From native part of the app, user can navigate to WebView part. And, somehow, web page should identify user. I have authorization token stored in the app and of course I can pass that token in the headers of the WKWebView. And other stuff will be handle in the web (routing and etc). But is it a good and secure way of doing this? How can I easily integrate WebView in the app caring about token?
There are a few options here:
Using headers seems problematic according to this thread but hopefully you can get it to work. It feels like this will have reliability problems if the token ever expires in the web view, so you'll need to manage that.
Simple option: open a system browser - either Safari or a Safari View Controller. The user may have to sign in again though, which your stakeholders may not like.
More complex option: use the Javascript API to pass the token from the mobile UI to the web UI. This will give you full control, and the web app can call back the mobile app to refresh its token. It can be the best usability option if used sparingly. It requires tricky foundational work in both the web and mobile UIs though.
SECURITY
Passing the token from the Mobile UI to the Web UI is natural if both are part of the same logical application and access the same level of data. In this case option 1 or 3 would work.
If the apps have very different security levels (eg the web app is now getting a much higher privilege token than it usually gets), then I would not pass the token and would use option 2 instead.
FURTHER DETAILS
I wrote a quite detailed blog post on considerations a while back, and there is also a code sample you can run:
Blog Post
Mobile Bridge Code in Web UI
Javascript Bridge Code in Mobile UI
I'm not sure there is a "proper" way, but before I just bodge together my own incompatible implementation, perhaps there's something in all the standards that can fit my need?
Here's the situation: Apple has declared that apps on their phones MUST include all standard functionality inside themselves. No more iframes with web content! If you need to show stuff from web, open the system browser (Safari)! Unfortunately we need to display stuff from web, so here we go...
Now, the app requires authentication which the user has done previously. We store whatever tokens we need. When the time comes to open the browser, we don't want to force the user to re-authenticate. We need to somehow pass the access credentials to the browser, and preferably do this securely. Furthermore, the webpage in the browser will need a token obtained from our OpenID Connect server.
Unfortunately, the only point of communication between the app and the browser is the URL, so everything that we give will be there, in plain sight. I know that OAuth was pretty worried about this, so much so that they made it impossible to intercept authentication with just the stuff visible on the screen and instead using things like single-use intermediary codes, backchannels and PKCE.
Unfortunately I cannot see any way to use the default flows "out of the box" to achieve what I need. I can think of modifications to those flows that would do it, but I'm not a security expert so I'd rather go with something standard which is vetted by experts.
SCENARIO
It's a good question since many companies want to show existing web content in a secured manner within a mobile app, and to avoid an extra login.
WEB + MOBILE INTEGRATED SOLUTION VIA DISCONNECTED BROWSER?
Ideally what you want to do is pass the mobile app's JWT to the external web content in an HTTP header. iOS APIs such as openURL may not support this however.
You may have to pass a JWT in a query string, in which case I would try to follow a signed request model, though it is not trivial. I have used SalesForce signed requests though not implemented a full solution myself.
Mobile app calls an API method at POST /api/encrypt-token
API returns an encrypted payload that includes the JWT
Mobile app opens a web page at https://mywebapp?token=0a78904cwdu
Web UI calls POST /api/decrypt-token to get the JWT
Web UI stores the token in memory and uses it to call the API
You will want to prevent raw tokens being written to web server logs.
I believe the recommendation for this type pf solution is to use a one time key, as described in the above link. And of course the web session will have some limitations such as silent token renewal not working.
WEB + MOBILE INTEGRATED SOLUTION VIA WKWEBVIEW
In the past I've managed secured web content in a mobile app by making the Web UI get access tokens from the mobile app. This enables an integrated UX and you can use a 'standard as possible' OAuth solution.
When the Web UI runs within a mobile app's web views it no longer does its own OAuth handling and instead calls the mobile app to get tokens and trigger logins
This means there is a single login across web and mobile views, and the Web View gets all the benefits of mobile user experience, such as secure storage of tokens
The Web UI is no longer impacted by things like the web view aggressively dropping cookies
VALID USE OF WEB VIEWS?
Web views are probably not a good long term solution in most cases. I know that Apple are likely to reject apps in 2020 if they use any of these behaviours:
Use of UIWebView - the Cordova default - you need to update to WKWebView
Delivering an app that is solely a repackaged web site with no mobile views
Displaying web content of a dubious nature (ads etc)
I suspect that use of WKWebView used responsibly and justifiably would be accepted. I could be wrong though, so please don't take my word for it.
ONLINE SAMPLES
I will be documenting some stuff about mobile / web integration on my OAuth blog, including code samples.
We can send a link to someone formatted as okta:// and it will launch the Okta mobile app, but I would like to know if there is a way to deep link to a specific app in Okta mobile?
Something like okta://appname
or better yet would be okta://appname/specificpageinapp
I have tried all sorts of options, but none seem to work.
The Okta Mobile app doesn't support deep linking as you described.
You may be able to deep-link directly into native iOS applications using a similar URL Scheme (exampleapp://page/example). If the native iOS app is integrated with Okta, this might work as you expect.
However, it sounds like what you might actually want to do is link directly into the embedded web view of a web application in Okta. If that is the case, I suggest reaching out to Okta support with a feature request and the use case that you're trying to solve, so that it can get the attention of the product manager for the Okta Mobile app.
We have an iOS native app, that allows for online giving for churches through a external web page. The native app opens the browser, and the once the user is done with their online giving on the web page it uses a URL scheme to return back to the native app.
This works great, but isn't ideal because when the user later returns to their web browser they see the remnant of the external web page.
Currently we just do some JavaScript and clean up the page so to speak to avoid duplicate gifts etc. Is there a way we can redirect the page to the users default page, or home page?
Or is there a better way to handle this?
You could handle your online gift in an internal UIWebView, which would give you much more control over this aspect of your application.