I need some kind of authorization implemented in my IOS Native App (Swift).
I thought of creating an Active Directory Integration, but problem will arise when I will use the app from remote locations as in outside of the LAN. As the app won't be able to do an AD lookup (That is my understanding).
A solution could be to do VPN, but that is quite demanding of the users to require this.
Do you have any ideas on how I can have authorization which doesn't need AD-access and requires minimal user management (maintenance) when for instance people leaves and shouldn't have access anymore.
Any suggestions or ideas is welcome.
Related
My organization just blocked all native mail apps from accessing outlook, forcing us to use the outlook mobile app. They probably did this through conditional access through Azure AD, but I’m not 100% sure. I don’t want to do that, I like the native iOS app better. Are there any workarounds so I can start using the native app again?
There is no workaround to access Outlook with native mail apps if Outlook is blocked by a conditional access policy. That would be a huge security liability if there was a way to change an admin's access controls. As Sunny said, the best thing to do here is to ask the admin to enable this for your account.
I'm trying to setup Kahuna for my iOS app, and haven't been able to find a clear answer - the docs says that the secret key is meant to be used with the API Key for authenticating requests, but I can't find anything that states clearly if either of these should be kept secret/out of source code. Are these safe to put in my code, or should they be kept on the server side?
Thanks
Are these safe to put in my code, or should they be kept on the server side?
Short Answer is no for keeping them on the mobile app code and yes to keep them on the server side.
Why?
Because they will be static secrets in your mobile app code, thus they are easily extracted by using any reverse engineer tool, like using the Mobile Security Framewrok(MSF) to decompile the app binary.
Alternatives?
Well you can try code obfuscation, to generate the secrets dynamical in the mobile app or to store the secrets in the iOS keychain, but once more they can be reverse engineered at run-time, once more by using the MSF tool.
Possible Solution?
The best approach is to use a Mobile App Attestation service to protect the connection between the mobile app and the API server, that will guarantee at run-time that your App is not being man in the middle attacked, being tampered with, that is not running in a rooted or jail broken device and that is the same original one uploaded into the app store. This is done in the background without impacting the user experience by using an SDK integrated in your App and a service running in the cloud.
With this guarantees in place we don't need any-more to store secrets in the mobile app for Authentication, Authenticity and Integrity purposes, thus any access to third part services within the App can now be delegated to the API server that will be able to do a better job of protecting all the necessary secrets to access the third part services, like storing them in a vault.
You can find a Mobile App Attestation service in Approov(I work here) that provides SDKs for several platforms, including iOS. The integration will also need a small check in the API server code to verify the JWT token. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
I am trying to create an IOS application. Part of it will allow upload of data to a Dropbox account that is hardcoded. I don't know how to do this part of my app without having a webpage show up that asks for authorization. Are there other ways to authorize an account without asking the user?
Don't do this. You're asking for a disaster.
Violates the Dropbox Terms of Service.
What happens when Dropbox suspends your account, your app breaks.
An API key you hide in the app could be compromised and exploited.
Look into another service intended for what you actually want to accomplish, Amazon's S3 is likely a good choice.
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.
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.