I am in a situation where I make an iPhone app and a RESTful API (via a php script) to communicate with individual clients warehouse databases.
Currently I manually setup individual web servers with a self signed certificate. Create a user with a special long random password (it is hard coded into the app). Setup their web server so that my php script requires Basic Authentication and only grants access to the specific user.
On my app's side the username/password is hard coded and it ignores the fact that the server has a self signed certificate.
Is there anything wrong with this model?
Anyone could easily capture the username/password by pointing the app to their own server with Basic Authentication setup and a self-signed certificate.
To prevent this, you could also verify that the certificate signature (or public key) and the common name matches the self-signed certificate that you created (again, hard coded). This is known as certificate pinning.
Still, this assumes that the username and password are at least difficult to obtain by disassembling the code, and of course understanding that a hard coded username and password can always be stolen by a determined cracker who can read your disassembled code.
With the username and password, they can access your API on their own terms, of course, while someone else pays for the account.
Rather than hard code values into the app, can you have the app go through some setup process where the user enters credentials the first time? Even with this, an individual user's credentials may be stolen from their device, but at least it's a single user, and you can block access and setup a new account. This is the standard scenario.
Also, it may be feasible to release this to your customer using something like TestFlight (you can even roll your own) rather than through the AppStore. This will help limit the cases where individually built apps get into the wild, not to mention helping reduce the clutter in the app store.