I am working on an MS Teams app and testing it by sideloading it (upload custom app -> upload app package).
I have an OAuth flow that is working, but when I remove the OAuth page domains from validDomain of my app manifest, uninstall, and then re-install app with new app package/manifest, the OAuth flow still works.
Is there some sort of caching for sideloading that is enabling this behavior?
Related
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.
So, now twitter from 25 sep supports universal linking, it means that when UIWebView hits https://twitter.com/oauth/authorize?oauth_token link, it tries to open a twitter app, and if it is there, then it redirects me to auth page with auth error, so I wonder, how can I disable it from code, without uninstalling twitter app, or how I can enable universal linking auth in my xamarin ios app? Is it possible at all?
(similar question but for native: Disable Twitter Universal Deep Links)
Unless Twitter removes/updates the apps section of "https://www.twitter.com/apple-app-site-association" to allow a bypass or a secondary oauth that is not in the apple-app-site-association file I do not see how you would do it. These files are signed and iOS handles them at an OS level.
I have not played around very much with the continueUserActivity delegate and the NSUserActivity object that is passed to apps launched from UNI links, but I do not see a way for the launched app (i.e. Twitter) to return control to the original app, and at that point the oauth call-chain would be broken anyway....
Unique. Unlike custom URL schemes, universal links can’t be claimed by other apps, because they use standard HTTP or HTTPS links to your website.
Secure. When users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.
Via: https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html
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.
I'm developing a corporate web application.
The devices it is supposed to run on devices that have MobileIron and a corporate profile installed.
The app uses a corporate authentication service that authenticates based on client certificates. When I open the app in the Safari browser - the authentication is working properly. But in order to provide some of the features the app had to be wrapped in a PhoneGap shell. And the authentication has stopped working.
As far as I understand it is due to the fact that the UIWebView is unable to get the certificates from the device.
Is there any way to entitle it to or implement the handling myself?
Using MobileIron AppConnect, you can distribute certificates directly into those apps (instead of to the system keychain, which is only accessible to the built-in apps like Safari). The app can then be coded to provide that certificate to the web server when challenged. This is pretty easy to do.
http://support.mobileiron.com/appconnect will have the details.