I have spent quite some time now trying to get the webView handling up and running with the OAuth Authentication in the iOS app, and there are some limitations that needs to be addressed.
The pure api-calls with access token from the app works fine, but the problematic areas are whenever I should present anything in a webView. The webViews are sandbox within the app, and due to that I have little control over the cookies used to maintain a web-session. And with every iOS release, Apple is tightening this sandboxing, making interaction with web-view less and less available.
Problem:
There are basically two approaches to webViews in an iOS app
1: WKWebView: I have somewhat control over headers and requests being sent from the web view. I have tried inserting the Authorization header in the initial request, and result is that only parts of the loaded web-page is authenticated. I have also tried intercepting the partial loads in the web-view by adding the Authorization header to those requests. This improves the situation, but there are still some partial loads that I am not able to intercept properly and therefore parts of the page-loads (through links clicked, resources loaded etc) are not authenticated. I have the possibility here to handle persistent cookies fetched from the pure api-calls, but no means of inserting PD Session Cookie.
2: SFSafariViewController: With this approach, the only parameter available for me to manipulate is the initial URL sent to the webView. I have no possibility to manipulate headers or insert any kind of cookies.
Proposed solution
In order to ensure that the user is logged in in the webView session, it would be preferable from my side to pass the access token as a query-parameter in the initial url loaded into the view. With this approach isam could from server-side ensure that if the initial request contained that access token, ISAM could set session-cookies that would be valid throughout the lifetime of that particular webView session.
From a web-browser perspective, I see the point in that we might end up with the access-token visible in the browser-history. In order to avoid sending the actual access-token in the url-request, I propose instead that whenever I want to show a web-view, I first request a short-lived token (with very short expiry-time) that I can pass as a query-parameter in the initial request of the web-session. When you receive a request with this short-lived token, you validate that it is still valid, and set all needed session-cookies in order to make sure that the web-session is regarded as valid.
I would from the app prefer that the SFSafariViewController is used for the webView implementations. The reason for that is that this will ensure a better user experience for the pages hosted by webViews. The web-experience will be closer to what we see in the browser, and the implementation is a lot less vulnerable to server-side changes of the web-pages breaking the app. (In short different iOS versions impose different limitations on js/html handled in the webViews, and makes testing/handling of all scenarios really extensive). With the SFSafariViewController solution, this would be much less of a problem, as the webPage is then handled by iOS in a "safari-context" and the implications of doing server-side changes in the web-pages is a lot less error-prone.
So, if it would be possible for you to implement a solution as described above (with a short-lived token I can pass to the webView as a url query-parameter). Do you think such an approach would be ok to implement?
------------------------------
Piyush Agrawal
------------------------------