I'm developing an enterprise application for one of our clients that utilises the GoogleSignIn SDK an a login option.
During development, I was surprised to see that support for the SFSafariViewController had been added meaning that I could streamline my login process by sharing Safari cookies.
This was all great until the client raised a critical issue being that once a user logs into the app (via Google and SFSafariViewController), they could log out of our application (including the GoogleSignIn SDK (see below))
func signOut() {
...
let signIn = GIDSignIn.sharedInstance()
signIn.signOut()
}
However the user remains signed into their Google account via Safari. Something that would be extremely helpful on a personal device but i've been informed that there is the potential for 20 people on a single site to be using a single device.
I've looked at setting allowsSignInWithBrowser and/or allowsSignInWithWebView to false however I cannot get it so that the SDK will use only a web view (such as UIWebView or WKWebView) where we can ensure that credentials will only be persisted within the application.
Is there such functionality to achieve this that I am missing? I think it could be quite critical in some use cases that such configuration is available.
Related
We are developing two new react native apps, and need to integrate Azure AD authentication at both the places. We also have existing web apps that are Azure AD enabled and the user can open the web links from our (new) native apps.
We have decided to use MSAL library (react-native-msal) to implement the authentication part mainly to support SSO between the native apps + the web apps that we open in the Safari browser.
We have followed all the steps that the react-native-msal library suggests and are able to achieve SSO between the two native apps.
However, when I login to one native app, and try to open the web app link using react linking, the web app prompts for the login credentials.
Note:
For authenticating user through native app, we are using "Authentication Session" with "prefersEphemeralWebBrowserSession = false" which ideally should share the SSO cookies with the Safari browser.
But clearly, this does not seem to work.
I would like to get some understanding on this problem and find out if others are facing this issue too? or is it just us?
In this case you need a preferred user token and send it along with the login request. For capturing the details of the user at the same time I suggest storing the details in the domain wide cookies that is known for all applications.
// Store the user details after login
document.cookie = "msal_details=Paul#xyz-corp.com;domain=.xyz-corp.com;path=/"
// use the user details
var user = getCookieByName("msal_username");
userAgentApplication.loginRedirect(scopes, "&login_hint=" + user);
Lastly, you would need to implement this in your application.
Well, it turns out to be a problem with the simulator. This functionality works only on the physical devices (iPhone/iPad) and not on the simulators.
This should have been documented in the react-native-msal's document though.
I know that SFSafariViewController has private cookie storage and other implementations. However, I know that we may write an extension for every (every native system) Swift class.
I need either to share cookies with native Safari, or to open Safari from my app with some header request. At least, how to create an API for getting/setting cookies?
Cookie sharing between SFSafariVC and native Safari has been disabled in iOS >= 11.
At WWDC, Apple announced a change in the behavior of Safari View Controller with iOS 11 in that stored data (cookies, local storage, etc.) will no longer be shared between instances of Safari View Controller. We've confirmed this in-house with a beta version, and this seems to be independently confirmed by the folks at Branch.
From AppAuth-iOS' repo: user whitehatguy
The only API for SFSafariVC is to create a new instance for a given URL. You can't set or modify cookies.
If you need to execute custom code, have a look at WKWebView (iOS >= 8) / UIWebView (iOS < 8). Useful answers: Getting cookies in WKWebView
SFAuthenticationSession was created to allow SSO/OAuth authentication flows, which shares cookies with native Safari but developers have no direct access.
A class that manages sharing a one-time web service login, along with cookies and website data, between Safari and an app, which can also be used for automatic login for other associated apps.
The two cases where you would use SFAuthenticationSession are:
Logging in to a third party's service using an authentication protocol (e.g. OAuth). This option works well for social network applications.
Providing a single sign-on (SSO) experience for applications. This option works well for enterprise companies that have many applications installed on the same device.
SFAuthenticationSession's documentation by Apple
My iOS app currently offers users the option to log in and sign up with their LinkedIn accounts. I am using this project for the LinkedIn log and OAuth: LinkedInOAuth
With the update to iOS 9, my app now occasionally crashes, when a user attempts to log in through LinkedIn using that project, with a runtime exception of WebThread(18): EXC_BAD_ACCESS(code=1, address=0x8)
To resolve this occasional crash, I turned to an updated version of the project I was using that conforms to ios 9 and linkedin's ios 9 SDK.
The issue is that while this new project has solved the WebThread crashing, it now requires users to download LinkedIn's app (if they don't have it) in order to log in to my app with LinkedIn.
The previous project never had such requirements and would present a webview that allowed anyone with a linkedin account to log in.
My question is am I wondering if it is possible to authenticate with LinkedIn in ios 9 without requiring the user to download the mobile app? My hopes are that it is possible to update the old project to conform to ios 9 while simply presenting a webvew. Thank you!
We only discussed this last week (at the time your question didn't have an answer, but happy to update you now—that is, if you haven't solved this in the meantime).
After scouring several sources I came across this:
Mobile vs server-side access tokens
Presently, there is no mechanism available to exchange them. If you
require tokens that can be used in both the mobile and server-side
environment, you will need to implement a traditional OAuth 2.0
solution within your iOS environment to acquire tokens that can be
leveraged in both situations.
from: https://developer.linkedin.com/docs/ios-sdk-auth
The premise being that via mobile solutions, they offer single sign-on thru their app. This works, but requires their app. Apple's approval process has swung both ways on this, and it appears that it is a flip of the coin as to whether they will allow this or not (the requirement of a third party app). #AroundThen didn't have any luck and his app was rejected due to the requirement, however, other users* have indicated Apple weren't adverse to it in their application processes.
Alternatively, their is the web logon process using OAuth2. This is pretty stock for their non-mobile solutions. Currently sharing the tokens between mobile and web solutions is not a default and if you want to share the same token their solution is that that is listed above.
In essence (and copied from my other answer here):
You can test for the presence of the linked-in app:
if it is not there: implement OAuth2 directly through your app
if it is there: use it or your OAuth2 implementation (which you'd probably err on the side of using their app for the link-ability between any features of the app you may need in yours).
Thereby avoiding the REQUIREMENT to have the app installed, but utilising it if it is.
This suggests that authentication away from the app is supported.
Reportedly, #AroundThen has had success with this process.
Good luck!
*1 I'm currently having trouble finding his post, but basically he provided login credentials that Apple attempted to use, but had locality issues and hence couldn't get in, but it was inferred they may have approved it if they had of.
It seems this used to be possible, but not anymore. Here's my dilemma: I'm creating an iPad educational software app, and I want to let students log in with their Google Apps for Education accounts using OpenID-Connect.
... I guess my first question is: is the current Google+ SDK the right way to perform login against GAFE? What about the forthcoming "Google Classroom"?
So say I do this - the student pushes the "login with google button", the sdk performs an app switch to safari and lets the user log in to their google account, push the permissioning buttons, and app-switches back to my app, and the user is now logged in. Fine. At the end of the class period, the user logs out of my app and hands in their device. The next period, though, another student logs in, and because the first user has forgotten to also log out of google in safari, the second user has access to their account.
... My second question is: is this a valid concern? Seems like this would be a pretty common usage pattern.
... Third question - can I get around this? Can I make Google+ sdk use an internal UIWebView, or no web stuff at all? This is what seems like used to be possible, but no longer...
EDIT: Spoke to google tech support for apps-for-enterprise (thx M!) and they say that there is no way to authenticate against google openid-connect without going through a browser. This is, I believe, a security problem - students being kids, they will forget to log out of the browser, and the next kids will get into mischief. Oh well.
The GPPSignin class describes itself as:
It provides single sign-on via the Google+ app (if installed), Chrome
for iOS (if installed), or Mobile Safari.
Internal web views are not mentioned. You may need to implement OAuth2.0 on your own to allow your internal UIWebView to manage authorization.
Google publishes an API which includes a method to signOut. You can use it at your app's discretion in addition to the SDK requirement that a user be able to sign out manually.
https://developers.google.com/+/mobile/ios/api/interface_g_p_p_sign_in
I have an angular app that painlessly integrates with Firebase's SimpleLogin service for Facebook on the web, however, it relies on opening a pop-up to do so.
Although iOS 7.0.3 seems to have fixed some severe bugs where alerts and popups were not functional in fullscreen web apps (i.e. after 'Add to Homescreen'-ing a website via Safari), the Facebook login fails after redirecting to Facebook and granting approval, landing back on a blank page (which requires an app restart to remove).
I suspect this has something to do with the was Facebook is redirecting back, but AFAIK I don't have control over that, nor would hacks like these fix this.
Are there any workaround that exist for this problem?
[Engineer at Firebase] Support for redirect-based OAuth has been added to the Firebase Simple Login Web Client as of v1.3.0, available from the Firebase CDN or via Bower using bower install firebase-simple-login.
This update enables the Firebase Simple Login client to detect iOS "standalone" applications and handle the redirect-based OAuth automatically in your application.