I have a need to set some context via Safari (a context token), and then read that context from a native iOS app. What are the best practices for doing this?
A couple thoughts so far:
Set the context in an HTML 5 database, but I'm not sure this will work because the database might be only accessible from Safari. Would using a WebUIView in the native app allow me to access the same HTML5 database / local storage as Safari?
Set the context in device storage, but I'm not sure this will work because I don't know if Safari can actually write to device storage.
I would suggest one of these two options:
Let the web server keep track on the user both in the app and on the website, for example by creating a user account.
or
Pass the context token to the app immediately via an URL-scheme by registering your app as a protocol handler, see more info here
Suggested way:
Send e-mail with link and context token, when user clicks link, save context token in cookie in safari, then redirect to appstore for app download.
When the user downloaded the app and opens it, present a button for the user, when the user clicks it, open a web page in safari.
Safari loads the cookie with the context token, and then triggers another link using a URL-scheme like yourAppName://contextToken=12345678. The link opens your app which reads the context token from the URL.
There is no best practice for directly sharing data between safari and a native app directly and that it is simply not intended that you should do that. All cookies and storages are sandboxed for each app and safari has its own sandbox.
Letting your server doing the job via user accounts is the best and clean way i.m.o. That is why you have user accounts. If you didn't try out the protocol handler for reading specific URLs, that could also be made handy I think.
Could you have the app hit a URL on first launch hosted by server which is redirecting the user in safari, and compare IP addresses, time, iOS version, etc to get at least an approximate match? If an approximate match is insufficient, you could, when you see an approximate match, have your app open safari to confirm their identify via cookie.
It’s easy to send messages between a UIWebView and your native up using WebViewJavascriptBridge.
In your case, though, the accepted answer’s suggestion of using a custom URL scheme (directly from email to app, post-install) makes the most sense.
Related
On iOS 11, Apple introduced a new way to share auth data between the web and a Mobile App with SFAuthenticationSession.
It would be a bad user experience to show the SFAuthenticationSession prompt to every new users - that might have never used my website - to have them agree and then get nothing out of it and have ask them to login.
The documentation is pretty empty on Apple side. This is the only example I found.
Is there a way to know if there is a cookie available before showing the SFAuthenticationSession prompt? Or maybe, with the Associated Domains enabled, when authenticating with my domain, the system should not show the prompt?
No. Even if there aren't cookies, the user can login entering his username/password and then clicking on "Login"/"Enter" on the website (E.g: Facebook, Instagram).
Accessing the cookies won't be enabled:
When the webpage is presented, it runs in a separate process, so the user and web service are guaranteed that the app has no way to gain access to the user’s credentials. Instead, the app gets a unique authentication token.
Official docs
Working example for Instagram-OAuth: https://github.com/dvdhpkns/SFAuthenticationSession-Instagram-Oauth
And the GitHub repo you added was posted by the author to send a bug report about errors in cookie sharing for local servers (rdar://33418129. Original tweet)
Are cookies shared between Safari and SFAuthenticationSession?
#DVDHPKNS
They’re supposed to be shared, but we have some timing bugs right now. Please do file bugs about what you’re seeing.
#rmondello (Apple employee)
P.S: They added more information to the docs since your original post date.
I'm developing an internal app that will leverage our corporate Google Drive accounts and will be used on shared devices (iPads shared among teachers and students at school sites).
Is there a way to force GIDSignIn to require a password with each sign-in attempt? Right now, even after calling GIDSIgnIn.sharedInstance().signOut() (or GIDSignIn.sharedInstacne().disconnect()) the user doesn't need to enter their password the next time they access the app. That means, when the device is taken by the next user, they could very easily access the other user's account.
Am I missing something? Do I need to somehow clear the cookies store in the UIWebView that the GIDSignIn process uses?
Where available, the GIDSignIn login process uses a SFSafariViewController, not a UIWebView. It leverages the cookies (as well as passwords) stored in Safari, for a quicker login.
I don't think you would be able to clear such cookies. You should be able to force a Google log out, though, by opening https://www.google.com/accounts/Logout in an SFSafariViewController, though the interaction with the rest of your app may be a bit weird. See Logout link with return URL (OAuth) for a way to provide a return URL which you may try to use to control the process (you'll need to use an URL scheme to return, though).
Note that iOS may prompt to save login information, and then provide said login information to subsequent users. You'll need to disable that in Settings -> Safari -> AutoFill
There may be other ways of achieving it via configuration of the device, but iOS is not really designed for multiple users at the moment.
In my app I need to implement next feature: when user logged-in in the app, it (the app) needs to save cookies (or any other data) for certain website to mobile Safari. The goal is to not make user log-in next time when he will open that website in Safari.
Documentation says that it can't be done on iOS using cookies. Does anybody know any other solution? Required feature of implementation is to make it 'silently' to user, without opening Safari.
UPDATE
Is it possible to access app data from mobile Safari and get some callback? For example when user browses website the site sends some callback to the app and gets some response with user' data.
Old question, but could you open Safari to a special one-time URL from your app which takes user to a page which you host, passing a token which you retrieve from API on same server, with page then validating token and setting cookie? That way authorization is handled on server, and server can set the cookie in the response.
You could do something like this in your app
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:#"https://myhost.com/myhandler?token=PX2G16BWFKZBQWUKGF3BGRY2Z6BEJ7Z3PMO2GZ6S3R00JVWBVEO6VWBEXNK14IBJ5GKAY5EKBLAHNSAJ8"]];
Then page at myhost.com/myhandler would read and validate token, and set cookie on response, and then invalidate the token. You could also add a time limit for how long the token could be used.
You can't access the safari cookies.
Safari's cookies are not accessible from other apps. Each app is given
its own WebKit cache and cookie stores, so while cookies will persist
within the same app, they aren't accessible between apps.
The Scenario:
A web application that once a new user completes the registration, an email will be sent, containing a URL that once tapped from within an iOS device, the iOS app will be launched. This scenario is a classic scenario to make users use the mobile app.
While implementing it (using URL scheme), we start wondering how secured is this method? Theoretically - a malicious app could sign up to the same URL scheme, and according to Apple:
Note: If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme.
Implementing Custom URL Schemes by Apple
In such scenario, if a user is tapping the url inside the email, it is unknown which of the two (or more apps) will be launched - ours or the malicious one. Lets say a different app is being launched - if its really malicious, theoretically it could mimic the login page of our app and grab the user's credentials.
Are there any best practices that handles such scenario? I've read many articles regarding the issue, all of them claims that the only solution is to wait for Apple to make these url schemes unique.
example1,
example2
I would love hearing about any solution to the issue if exist,
Thanks in advance!
We have to assume the malicious app can intercept any data included in this url and that it's author has been free to reverse engineer any behavior included in your app so it can imitate your UI and any validation your app attempts to perform. However we can also assume that the malicious app is contained in its own sandbox so your app can communicate with your backend privately. The malicious app can imitate any such communication but this does allow us to construct a secret unknown to the malicious app. That gives us at least an opportunity to design some countermeasures.
One option might be:
As part of registration construct a public/private key pair and store it in your app.
Send the public key to your web backend as part of the registration process.
Encode they payload of your URL using that public key.
Now we've sent data to your app which might be redirected to a malicious app but which the malicious app cannot read. That's a partial solution. We still need to be careful to design a UI which does not encourage a user to fall for a phishing attack since the URL might still launch the imposter.
The encoded data might be a token we can use to authenticate the user and therefore never require them to re-authenticate within the app. Then there is no login screen to imitate (though a clever forgery might still be enough to trick users into divulging their credentials).
An alternative might be to use a similar per-user secret stored on the client as a salt to combine with the user's password. Their password alone might then be insufficient to authenticate so a malicious app capturing their credentials is not immediately able to access their account.
Another design could be to allow the user to customize their experience in a recognizable way. You might show their selected profile image on the sign in screen. If that selection is known only to your app then an imitator shouldn't be able to duplicate it reliably (again, no guarantee that means users will catch the deception).
All of this introduces tradeoffs; users might still be tricked into revealing information to malicious apps no matter how different they appear from your legitimate client, client side secrets can be extracted by other attacks, and you need a plan to support users who switch, lose, or upgrade devices. You have to decide if any of this actually improves the security of your users and if it is worth the cost to implement.
Try something like this:
In your email, state that clicking on the URL will launch the app and log you in for the first time then prompt user to enter their new password. Include a token in the URL which, when handled by your app, does a one-off login and put the user on a "New Password" page.
If a malicious app has also registered your custom URL and steals the link, they should (hopefully) not be able to do much with it. Even if they replicate your interface and prompt the user for a new password, it's not going to achieve anything.
edit: After thinking on this further, as long as you have an active attacker, you're pretty much screwed. The attacker could continue to emulate your app, effectively MITMing you, regardless of what you do, as long as they're able to hijack that initial URL. My solution would only work in the most basic of cases, not really reliable.
I'm trying to intercept link and login a user, then send them on to Safari and have the page load with no authentication request.
So, what I'm doing so far...
I register a custom URL scheme for my app. Call it "myhttp". Now someone clicks on a link (say from an email) of myhttp://secured.com/foo and my app runs. The apps pulls the user's credentials from somewhere and makes a call to the real URL with an NSURLConnection. The NSURLConectionDelegate implements connection:didReceiveAuthenticationChallenge and I navigate through the security layer fine. Next I try loading the same url using the UIApplication openURL method to bring up Safari, but I still get an authentication check.
I thought this would work because I read the follow in the Apple documentation.
Credentials stored in persistent storage are kept in the user’s keychain and shared among all apps.
And when I check the NSURLCredentialStorage I can see the credentials I just used stored there with the correct information, protection space, scheme, etc, but clearly I'm doing something wrong or I wouldn't be getting an authentication challenge when I switch to Safari.
So the question is, did I just screw up somewhere along the line, forget some important bit or am I going about this the wrong way?
This wasn't possible before iOS 8, but is now with the Shared Web Credentials feature.
Add a com.apple.developer.associated-domains entitlement to your app.
This entitlement must include all the domains with which you want to
share credentials.
Add an apple-app-site-association file to your website. This file must
include application identifiers for all the apps with which the site
wants to share credentials, and it must be properly signed.
When the app is installed, the system downloads and verifies the site
association file for each of its associated domains. If the
verification is successful, the app is associated with the domain.
An app can share credentials with any associated domains by calling
SecAddSharedWebCredential and SecRequestSharedWebCredential.