We use OAuth2 client-side flow. Many pure client-side apps use the same technique - pigshell is not blazing any new trails here. Only the code you run that's h

We use OAuth2 client-side flow. Many pure client-side apps use the same technique - pigshell is not blazing any new trails here. Only the code you run that's hosted on pigshell.com has access. The permissions are tied to the app-id which is embedded in the code. The access token is persisted in your browser either as a cookie or explicitly in localStorage. We don't and won't support OAuth 1 (Twitter, Flickr etc), which lacks a pure client-side flow, just to avoid the issue of users having to trust the pigshell.com server to generate (and not leak or misuse) the access tokens. Here is a rough guide to local setup: - Check out the git sources, run "make" (some more details here, but reading the Makefile should help) - set up apache to serve the virtual host pigshell.com (if you want to use Dropbox, you need to create a self-signed SSL certificate and set up https as well) - modify /etc/hosts and set 127.0.0.1 to point to pigshell.com This way, static assets as well as redirect URLs from the OAuth2 server will hit your local server rather than pigshell.com