Let say i have an android app with Reddit OAuth2 authentication. I initiate authorize request with my client id and user accepts the consent. Now i got the authorization code which will be exchanged for token in my server via HTTP request. This process will protect my client secret as it is in my server, but it actually doesn't. Anyone can take the client ID from the app by decompiling and initiate authorize request to reddit and exchange code for token from my server. They don't even need to know secret to get the token.
How can one protect the API against this kind of misuse (or attack?)?
Is there any way i can allow my API to accept requests only from my app and reject other requests (using SHA256 or etc.)?
I have looked up and studied about PKCE. But this is not useful in case as it only protect again code sniffing/intercepting and accept only the original authorize request initiator.
You will probably want to store a secret. When first opening the app (and after certain interval of times to keep it secure) you will need to generate a keypair. Store the private key on the device's Keystore and send over the public key to your backend. When authenticating to your api, sign the client's secret with the private key and verify it using the public key on the backend.
Note that this will induce substantial overhead to your login process. Because mobile devices are not necessarily well equipped to perform cryptography. Though this is less and less true.
EDIT: Your keypair will need to be issued from a CA you trust, otherwise this is all useless.
I am creating an application which is like a template where every service provide can enter their details in the setting on the web and just change the app name ,app icon, new bundle identifier and upload the app on app store.
Till here it was good, But the problem for me is that I have a push notification services in this app.
And I have read on the apple document that every bundle identifier should contain a unique push certificate. And from there we create a .pem file, so that means every app will have a different- different pem file.
But I want a single pem file which will work for all app.
Can anybody please suggest me what should I do, or what is the proper way to go about it?
Unfortunately, what you are asking for is not currently possible with Apple Push Notifications Service. Though you could conceptually use several of the optional arguments in openssl to generate a Certificate Signing Request (CSR) using the exact same keypair, the root issue comes from the 'Certificates, Identifiers, and Profiles' tool in the very first step in creating a new APNS certificate:
As the supplemental instructional text reads: "Note that only explicit App IDs with a specific Bundle Identifier can be used to create an [sic] Push SSL Certificate", which means that we can neither provision a Wildcard App ID for push notifications, nor can we specify 'All App IDs'.
If we briefly step into a hypothetical world where the "Which App ID would you like to use?" question doesn't exist and instead went directly to the step where we upload our CSR, the certificate we would get back from Apple would do exactly what you want -- It would authenticate the server you use to construct APNS payloads as one legitimately belonging to you and authorized to send pushes to the APNS Gateway. It does, however, open an important security concern -- If you can use this one server (or 'provider' in APNS parlance) to send pushes to any of your apps (so long as you know the device's APNS token), what prevents you from using your provider to send pushes to my apps? Or if we turn the concern around -- what would prevent me from using my authorized APNS provider to send your apps push notifications? Or to send pushes to your customers with misinformation (ex. 'Regrettably MyApp is closing its doors and exiting the App Store. MyApp recommends customers purchase CompetitorApp to maintain your service!'). This slimy, scam-prone world we thankfully don't live in...
Instead, Apple requires 3rd-party developers to select the AppId for which payloads from a particular APNS certificate will be honored. Then even if I somehow manage to acquire your customer's app's device token, I won't have your server's private key and thus could not successfully deliver a scam, spam, or otherwise rogue APNS payload to your customers.
Ok, I got it already! Since I can't use a single certificate for multiple App IDs, what can I do?
Given some of the background in your question, it sounds like you've put in the effort to make your app highly configurable. In your own words "[it] is like a template" - which would suggest that on the server-side of your app, you have some mechanism in place to be able to be able to identify what app is making data requests and which provider's data to send back. Your APNS Provider logic would need to have similar intelligence built in. Depending on how you are currently making these server-side distinctions, you may be able to reuse some of the existing logic; you are the one who will have to make that call. The remainder of this answer will offer a high-level approach to how you might choose to setup your provider owing to the one-pem-per-app requirement APNS imposes. In general:
Place a copy of the signed .pem in a secure location on your APNS Provider
Update your Provider's 'register device token' API to accept both the device token as well as some way to uniquely identify the app for which this token is valid (...maybe as simple as just the App ID itself!)
Update the iOS App to pass both it's APNS device token and that App Identifier to the freshly updated 'register device token' API on your provider.
Update your Provider's logic to use the correct .pem when delivering a payload to the APNS Gateway.
For the sake of good process, ensure that you have a procedure to update or retire an application's .pem, data, and relevant tokens.
For each app that you make from your template, you already have to generate a unique App ID and App Store Distribution provisioning profile. When doing this initial setup, you can also request the APNS certificate and treat all three pieces of data as app-specific settings. Install the APNS certificate into your provider along side the .pem file for your other apps so that you can grab it when it comes time to send an APNS payload to Apple.
If you've done APNS work before, you know that your provider is responsible for tracking app-specific device push tokens, generating and transmitting the APNS payload to Apple, and optionally using information from the APNS Feedback API. When your app connects to your provider to register its token, you'll also need to know for which app that token is valid so that you can select the right .pem for sending APNS payloads. This is key; if you don't have a way to know which tokens go with which App IDs then you will be unable to select the right .pem file during payload generation and dispatch.
Updating and retiring software is a key part of all software, but is one that doesn't always get the attention it should. Make sure you've considered how you'd go about refreshing the .pem file (which you'll have to do each year before the current one expires) as well as how you'd go about retiring an application without disrupting the other apps your provider services.
The answers to each of these questions is very much dependent on how you've architected the various components of your app, Xcode project configurations, server-side technologies, and server-side logic. Only you, or your team, can make the right call based on the details that make up your software. Best of luck and let us know how things go.
We are currently trying to create our own system, where users can create user accounts using their iPhone. However, we're not sure how we can securely create accounts for users with their own password set and everything. I've been told this is only possible with HTTP requests, which doesn't really look safe.
You can always encrypt the data you send via http
See answer to this question for the link to the tutorial:
AES 128 Encryption for iPhone HTTP Stream
What is the best/easiest way to authenticate a user from an iPhone client to a PHP/MySQL web-service? I have not set any authentication up and I want to keep track of the user so when I call my services it sends the username. I want to make sure this user is unique and if they lose their phone they will be able to re-download app and login with credentials.
This is very open ended question. Can you please provide some use cases that way we can help. If you are talking about Secure Authentication then just use HTTPS:
HTTPS was designed specifically to:
1)use encryption to defend against packet-sniffing
2)use certificates signed by an authority to defend against MITM
Is there any way to bundle a certificate in my application - and then use that to perform HTTP GET/POST using a NSURLRequest?
I.e. the certificate should not be used for other HTTP traffic on the device, only by my application.
Cheers
I don't believe so, but since all applications are sandboxed any special authentication measures you may have within your application cannot be accessed by other applications.
Best (in my opinion) you put the private key and certificate that you want to use on the keychain (or keychains of other 3rd party apps that share the same provisioning certificate).
As for the actual loading of the p12 we do use openssl (we did write a obj-c wrapper around it) to decode the .p12 that we send to the app (you can always use .DER or .PEM to ship the p12 with your app)