CODEWITHSUNDEEP
iosauthenticationmobile
mkral
mkral

Reputation: 4085

Authenticating Requests from iPhone with Framework API Token

So I'm creating an iOS framework that will be a static library that developers will add to their project, when they create an account on our site I'd like to give them a unique token that they put in their app to use my static library.

For iOS dev's, think TestFlight, you sign up, get an App ID and then run [TestFlight takeOff:<#some-key#>];

I'd like to authenticate the requests that the framework makes to my REST webservice (using https).

Is there anything I can do to prevent people from "breaking into the app code" and stealing the developers api token and using it to make requests? My api endpoints will not be public information, at least for now. and I can't authenticate the user because it's a framework and that would be an awful UX.

The question is, is there anything I can do to prevent this sort of behavior? Should I even care? I will charge the developer per X requests eventually so I was hoping to authenticate this so we don't have spammers racking up a bill for the developer.

How do other iOS frameworks handle this?

Any design ideas and criticism welcome.

Upvotes: 3

Views: 158

Answers (1)

Mr. T
Mr. T

Reputation: 13055

I'm not sure what you're trying to do is ever possible. If the text is in the client code, it can be pulled out. SSL-pinning won't really help you here either because the cert is in the client binary as well.

One way you might be able to get close is to use the developer's authentication system. Say a user logs in into the developer's auth system, then server side you generate a short-lived key for that user. Then the client code can be passed (over SSL-pinning) that short-lived key and use that to make your API calls. However, this requires the developer to actually have a secure auth system, and without SSL-pinning, they're vulnerable to a simple man-in-the-middle attack which will reveal the short-lived key.

You can try to minimize the damage by throttling API calls on your end, or trying using per-app heuristics to approximate what normal API usage would look like. Anything out of the norm will get flagged as potentially hacker based. That might be enough to flush out most of the wanna-be-hackers. The true hackers will learn of the throttling and be clever about circumventing it...

Your safest bet is to make it a server-side library instead of a client-side library. However, that's certainly not a super-sexy solution either. Not all apps have a server side component... and even if they do, once the developer's server is compromised (ie. gets spammed or hacked, etc) it's game over once again. But, in the end, the nice thing about a server-side solution is that you're at least less vulnerable to an attack and you put the responsibility of securing the system on the developer.

What's really lacking here is some form of Apple-based verification for network calls originating from Apple devices.... but that probably won't ever happen. :)

Upvotes: 1

Related Questions