Separate Request Quotas for Authorized [app]s

Question

Imagine, if you will, you have a popular [app] hosted on a cloud computing service which is also used by a number of other [app]s. If this service forces clients to share IPs (and they all do, in practice) its more or less inevitable that you'll fall afoul of our request quota system, which is IP based.

This was a theoretical problem until recently, when StackPrinter* (on Google App Engine) reported encountering this.

The Solution

In a nutshell, [app]s we authorize will be given a secret key which can be exchange (at StackAuth, via the /auth route) for a temporary authorization token. When that authorization token is passed on an API query (via the auth parameter) the request will be counted against a non-IP based quota.

/auth is the first POST method in the API, to use it one merely POSTs their secret key to /auth?key=<existing app key>. The response is a trivial JSON object containing either the temporary authorization token, or an error message.

What this means for your [app]

For 99% of all [app]s, nothing. This only really changes anything for server side [app]s, on cloud computing services, and even then only those with significant traffic.

If you're considering developing an [app] using something akin to Google App Engine, strongly consider alternatives. The handicap of a shared IP can be a significant one.

Does my [app] qualify?

Qualifying [app]s should

1. Run solely on a server
   • The secret key must be kept, well, secret. You can't do this if you ship code to a user.
2. Have actually encountered quota problems
3. Have a significant user base
4. Not be evil
   • Restricting how the API is used is a fool's errand, but we won't raise limits for any [app] we consider bad for the sites or community.

These are guidelines, not hard and fast rules, and each [app] will be considered on a case-by-case basis. If you think your [app] should be authorized, use the "Contact Us" link at the bottom of every page to send us a request.

About Security

This scheme will never be extended to client side [app]s. Nor will it live as long as the v1.0 API, at least we don't guarantee it will. There are a lot of little security issues with it, plus the elephant in the room of actually passing a "secret" token around.

The one real hardening bit (and one of the many things that makes it unsuitable for client side [app]s) is that an [app] can only have a single authorization token active at any one time. Subsequent calls to /auth with the same secret key invalidate the previously issued authorization tokens. Accordingly, any [app] that wants to use this scheme must be capable of some internal key use synchronization.

It is very likely that this entire scheme will be deprecated shortly after a more proper authentication scheme is introduced in later API version, it is intended as a stop-gap solution.

_{*Many thanks to systempuntoout for beta testing this scheme for us.}