I’m working on an appengine app which uses OAuth. Naturally, I’m dealing with multiple versions of the app simultaneously – a local version for development, a staging version and a deployment version.
To work with these, I need three separate sets of OAuth consumer keys/secrets as the callback on authentication is defined on the provider’s site.
I was wondering if there are ways for providers to provide multiple keys/secrets for a given app – this would seem to make more sense than setting up a new app each time. (Of course, it requires the provider to implement this, but it seems a natural thing to implement and I haven’t seen it).
More generally, what standard approaches are used to deal with this – my guess is register multiple apps and have logic in the app to determine if it’s in development mode, staging or deployment. Any thoughts welcome.
I find this to be one of the most annoying parts of being an OAuth API client developer. There is no reason why providers should not allow developers to register redirection (callback) URIs for testing.
The standard approach I’ve seen is to allow you to whitelist one or more domains for callback / redirection. Facebook has some crazy setup where they let you “register” multiple domains by using different domains for the various links in the application profile. I did not have much luck with that. Twitter is one of the better implementation for that, letting you register multiple domains.
In OAuth 2.0 (draft 18 or newer), this topic gets much better treatment. Registration of the full URI is recommended, with the ability to register multiple callbacks and select the one you want to you dynamically at request time.
The main aspect to consider is how you want to handle permissions with a staging setup? Do you want to be able to reuse existing approvals or want to keep those separate? Also, if the API provides special client-only calls (such as client storage or management tools), do you want the stage version to share it or keep its own (so that testing will not mess up production).
At the end, providers should provide a complete development environment and that includes testing facilities for API clients. Most don’t.