Plugin FAQ

Why don't plugins use OAuth?

OAuth does not apply here.

Don't believe us? Okay, here's our rationale. First, let's bring Overview's terms into OAuth's language:

• The OAuth resource owner is an Overview user
• The OAuth client is an Overview plugin
• The OAuth resource server is the Overview server

Here's what OAuth can't win us:

• OAuth could let a plugin access a user's documents on our server. So can our home-grown API Token solution.
• OAuth could let our server keep track of which plugin has which API tokens -- so we could, say, log out every instance of a plugin. But Overview already does that: Overview creates the API token and constructs an iframe URL that includes both the plugin's URL and the API token. So it knows which plugins have access to which tokens.
• OAuth 2.0 can't prevent an attacker from intercepting an API token and using it to access a user's documents. (It has unbounded tokens.) That would be nifty.
• OAuth can't check the identity of a plugin. It uses SSL for that (like Overview).

Here's what OAuth can win us:

• OAuth 2.0 tokens can expire. That would be nifty. Of course, we can do this ourselves, too....

Here's what OAuth would cost us:

• Every plugin would need to implement an OAuth client.
• The user would be prompted to authorize plugins. That's plain annoying: the only way Overview passes a plugin an API token is if Overview is made aware of the URL, and that can only happen if a server administrator or end user has vetted the plugin.