I've received the following restriction on a mobile web app which doesn't make any sense as SSO only applies to native apps..
"This application will not be accessible on iOS unless SSO is configured"
How do I resolve this problem?
You need to configure SSO for your native app using the Instructions for SSO in section 3 of the iOS SDK documentation - once you've done that the app will be accessible as normal.
If the app doesn't have a native iOS version, your app is probably restricted from being accessed from inside Facebook's native app due to not complying with Apple's policies about iOS-approved payment methods.
You'd need to take it up with your lawyers or Facebook's policy team if that's the case - all i can answer here is the info on how to enable SSO for your native app if applicable
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.
We are developing an iOS application in Xamarin, which will be distributed via MobileIron. We are also developing the Backend WebServices (rest).
What I need to know is, when a web service call comes to my API, I want to make sure, that the call is coming from a client who is logged-in to my app with his Active-Directory credentials, using MobileIron.
The MobileIron website has plenty of information, but is also a bit chaotic.
What MobileIron products are needed for my use case?
Whats the best way to protect my WebServices and allow just requests from our iOS Application with correct AD-Credentials?
Do I need the AppConnect SDK or can I just wrap the iOS Application in MobileIron? If I need the SDK, are there any examples?
Thanks in advance!
Cheers
Immi
Here is one way how it should work, we have this built up in our environment.
Assuming that the target devices are managed by the MobileIron MDM system with MobileIron Core (MDM) & MobileIron Sentry (Gateway -> Intranet).
You can configure MobileIron Sentry in this way, that a webrequest from an AppConnect enabled app (no matter if SDK included or wrapped!) will be authenticated with user certificate from device, Sentry obtains Kerberos ticket from domain controller for the user and then forwards the web request to a website / webservice where Kerberos authentication is enabled and the user has access granted.
There are many things to configure for this to work (CA, user certificate -> device, service account with delegation configured in AD, SPN for website configured in AD,...) and there is a good support document available from MobileIron to make this up & running.
It's to extensive to describe here all steps.
If this is already setup in the target environment (if there is already another AppConnect app), there are only a few steps left (SPN and MI app-specific AppConnect Config).
The good news is, that the app itself does not have to take care of the authentication. The MobileIron stuff does this on its own...
We've migrated to the latest LinkedIn IOS SDK which only supports single sign-on (SSO) authentication, in conjunction with the official LinkedIn mobile application. Our app works really well with this, however Apple will not approve our latest version, because it requires the LinkedIn app to be installed for the authentication to work.
We need a solution which handles the scenario when the LinkedIn app is not present, to use web authentication, however LinkedIn are very specific stating Mobile SDK-enabled applications require the official LinkedIn iOS app to be installed on the device to function properly" https://developer.linkedin.com/docs/ios-sdk - The Mobile SDK was released in July, so presume we are not alone in having our app rejected by Apple approvals.
Could you 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.
Researching for this I did find:
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
which suggests that authentication away from the app is supported.
Pleased to confirm that the solution kindly suggested by Madivad of using the new LinkedIn SDK if the LinkedIn app is installed and when it's not reverting to traditional OAuth 2.0 works fine. Apple are also back on our Christmas card list as they approved this latest version today within 40 minutes of submission:) Thanks Madivad for helping out with this.
In the Facebook App Settings ☞ Advanced ☞ Authentication I can pick "Web" or "Native/Desktop" as App Type. The info bubble says:
Only select Native/Desktop if you are a Native iOS or Android app,
device, or Desktop app
Actually I am none of those but my app is a Native iOS App as well as a Facebook Page Tab.
Question: Which App Type should I pick?
I did some research and found the following in the Facebook Android Tutorial (under Troubleshoot):
App type Web vs Native/Desktop. Does it matter?: No, it does not
matter. However it's recommended to use the type 'Native/Desktop' for
your app.
What does it mean it does not matter? That does not make sense to me. Why should I have a choice then?
I did some more research on SO and found this statement by #Igy (dev support engineer at Facebook):
If the app's type is set to 'Native / Desktop' it's assumed you
distributed the app's secret key with the binary, and thus the app
access token isn't trusted (and 'getAccessToken' in the PHP SDK will
only work when real users log in, it can't fall back to the app token)
Finally I found this in the Facebook documentation:
Note: Applications that are configured as Native/Desktop apps will not
be able to make API calls that require an application access_token.
I do need to make API calls which require an access token from my page tab app, hence my conclusion is to pick "Web" as the App Type, although I'm having a native iOS app using the same app ID as the page tab app. But will that have any drawbacks on the iOS app?
TL;DR: use 'web' unless you're putting the app secret into the iOS / Android binary
The primary difference (and also the reason that it says 'it doesn't matter' while also giving a recommendation) is that if you choose 'native/desktop' mode, it's assumed that you distribute the app binary with the application secret embedded and the app secret is considered untrusted.
In this configuration, API calls which use the app secret (e.g. creating test users, making API calls on behalf of the app itself like changing app settings, posting achievements, etc) will not work.
If your app doesn't need to use the app secret / app access token, setting it to native/desktop increases the security somewhat as there's one less attack vector for your app.
If you're distributing the app secret with your code you MUST use that option or users could easily determine the app secret and hijack the app itself.
I want to develop a lib for twitter which can achieve SSO and can display the name of app which uses this lib during APP authorization.
I know you can do this in apple using twitter framework, but I want to do this in Non-Apple platforms.
Any ideas please?
You could do this leveraging the OAuth capabilities available from Twitter. You could leverage a user's Web session if they are already signed in to twitter.com. See: https://dev.twitter.com/docs/auth
Any native (mobile) application SSO capabilities would depend on what the Twitter native application makes available. I'm not aware of any - but Facebook does offer such features: https://www.facebook.com/help/mobile/singlesignon