We have developed a REST API which is consumed by two apps: one running on Android and one on iOS. The API is not public - we built the apps in-house.
Does it make sense to give a different consumer key to each different platform (e.g.: one for iOS on smartphone, one of iOS on tablets, one for Android on smartphones...)?
One advantage of having several keys is being able to easily do device segmentation analysis (however, that can be done in other ways).
Any strong point for one of the two strategies?
What are the advantages and disadvantages?
Thanks.
In the context of OAuth, any application that runs on an end-user device (including iOS and Android devices) is known as a "public" client because the secret key is distributed along with the application.
This is in contrast to a server-side web application, in which the key can safely remain secret. Only permitted developers and operations staff have access to it. In the case of applications that are distributed to devices, even with obfuscation, it's impossible to guarantee that the secret won't be exposed to unauthorized parties (essentially anyone with your app in their pocket), effectively rendering the key publicly available.
Given that, there is very little significance, from a security perspective, for assigning unique client IDs and secrets to devices that access your API. A malicious developer could very easily use the public credentials to pose as an "approved" app.
As you note, you can use a client ID to do device segmentation, but there are other ways to do that as well, such as a User-Agent header that don't convey misguided security implications.
In summary, there is no real benefit to issuing unique client IDs to apps based on platform. However, it is important to consider how public clients factor into the security concerns when authorizing access to your API.
If you will make app developers to use several OAuth consumer keys for each platform then developers will not be happy! Developers will have to somehow manage these keys to your service. What if app developers need to reissue the keys? If they launching app on new platform? How much additional effort of you these developers will need to maintain the keys?
Also, consider some platforms that you are not aware of: new mobile OSes, strange devices, unusual use cases. Do you want to limit and control all variants of uses of your service?
One of the reasons why you might still do that is that you can sell your API services separately for each platform (and probably with different prices).
Related
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.
When submitting an app that contains cryptography, I know there's a checkbox you must check, as well as subsequent questionnaire you must answer. And if the app contains cryptography you need to go through complex Exporter Registration and Reporting process.
There are three specific cases I'm curious about:
1. Cryptocurrency wallets
One of the "exemption" clause says:
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
Does this exempt the app from having to go through all the complicated government approval process? Most cryptocurrency wallets only use cryptography for signatures and authentication, but I'm not sure how this applies to this case.
Simply put, do all Bitcoin wallet app developers have to get government approval before submitting the app?
2. End-to-End encrypted messaging apps
How about end-to-end encrypted chat apps? Do I have to go through the approval process?
I'm talking apps like Signal and whatsapp.
3. Does WKWebView + Webcrypto count?
What if I'm using WKWebView which contains access to webcrypto API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API inside the app, does this count as "contain encryption"?
From Apple FAQ:
Use of encryption includes, but is not limited to:
Making calls over secure channels (i.e. HTTPS, SSL, and so on)
Using standard encryption algorithms
Using crypto functionality from other sources such as iOS or macOS
Using proprietary or non-standard encryption algorithms
You didn't specify source of your "exemption", but I guess it is not from Apple guidelines.
I would say that your cases are using encryption or crypto so are in scope of this guidelines.
I found some more informations here - maybe will help you.
Keychain access groups and application groups are both segregated using the app's team id.
Named pasteboards are also sandboxed using the team id.
Kerberos SSO seems to work well, but opening the KDC to the internet is a security hazard so it can only really be used together with a VPN.
The Shared Web Credentials API works well between native apps, but has intrusive popups showing up every time you attempt to access or even just check for the existence of credentials.
libdispatch can send messages to arbitrary apps, but the payload is limited to 64 bits and the recipient app must be currently running.
No unique device identifier that could be used to derive a key for a cloud-based encrypted KVS can ever be shared between apps not on the same team id.
…is there any way to share credentials (or any data, for that matter) between applications signed with different team ids, on recent versions of iOS? Apple doesn't allow migrating IAP, Passbook, etc to new team ids and it's blocking my team from implementing SSO between apps with historical team ids (M&As, etc).
You can open the app with deeplink that will reopen the other app with the infos you want to pass along. That's good for login but can be cumbersome if you want to pass a lot of infos back and forth.
I'm building a suite of tools that integrate with Asana. These tools comprise a web browser extension and a web app (or Chrome packaged app). Do the browser extension and web app share the same API call quota?
Right now, API rate limits are enforced per-user. Until we released OAuth support, there was no way to distinguish between different apps (since users were always authorized by the same API key). In future, each app will get its own rate limit quota (per user). If you intend to make them separate apps (and have users authorize them separately) they would then get separate quotas - but if you're either using an API key for both, or sharing one OAuth app, they'll end up sharing their quota, too, even if we roll out the change I mentioned earlier.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.