API Security – How to Prevent Multiple Requests to a Public API

I separate Users/Profiles from Authentication on my apps. This might be an approach you can use. Especially if in the future you think you might add twitter or other authentication providers to your system.

Basically I create a table called Credentials that stores the unique UserID in my system and the Unique id the provider gives. Email is not good because the user might change their email with the provider. Facebook provides a unique ID for each user in their token.

When a user authenticates, I look for the matching provider ID in the credentials table. (Don't forget to record which provider because otherwise you might find a match for a twitter login when the user logged in with facebook). Finally, I grab the matching User in my system who has the same UserId as the credential record.

There aren't that many steps in reality I was just spelling it out. In truth I just need one query

select U.* from Users u
inner join Credentials on
u.userId=Credentials.userId
where Credentials.ProviderId =?
and Credentials.Provider=?

System stored username and password of course would look different. But you already know how to handle that.

Regarding requiring a separate login even when the user comes through facebook. Please do not do that...that is the most irritating thing to me as a user when I'm given the option to login through facebook and the system still requires me to create a password. I've left sites in the middle of registering for that very reason.

For the first question, your approach seems correct to me. You consume a token in the sendsms entry that can only be generated by the login endpoint. You could also use a generic token created by login, and not easily guessable (it would be equivalent to a cryptographically generated session ID), used as primary key to a database tuple. There you can store whatever you want (for example the number of SMS still allowed to be sent).

You can also store the "state" in a variable and protect it using, say, HMAC, continuously exchanging it between the server and the client, but you still require some server state to defend against replay attacks on non-idempotent endpoints; at minimum, you need a per-session incremental counter.

The second problem is trickier, and you need first to ask yourself what the difference in behaviour (as seen by the server) would be between the app with its logic, and a malicious user sending repeated requests. You might enforce a minimum delay between requests that is comparable to the maximum rate at which the app can be driven, so that there's no longer an advantage in using tricks rather than going through the app.