CouchDB
  1. CouchDB
  2. COUCHDB-420

OAuth authentication support (2-legged initially) and cookie-based authentication

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.10
    • Component/s: HTTP Interface
    • Labels:
      None

      Description

      This patch adds two-legged OAuth support to CouchDB.

      1. In order to do this, a couple of changes have been made to the way auth handlers are used. Essentially, the patch allows multiple handlers to be specified in a comma-separated list in the following in the [httpd] section of your .ini config e.g.

      authentication_handlers =

      {couch_httpd_oauth, oauth_authentication_handler}

      ,

      {couch_httpd_auth, default_authentication_handler}

      The handlers are tried in order until one of them successfully authenticates and sets user_ctx on the request. Then the request is passed to the main handler.

      2. Now for the OAuth consumer keys and secrets: as Ubuntu need to be able to bootstrap this i.e. add tokens without a running CouchDB, I have advised creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini or similar. This should get read by CouchDB's startup script when it loads its config files (e.g. default.ini and local.ini as well). There are three sections available:

      i. [oauth_consumer_secrets] <consumer_key> = <consumer_secret>
      ii. [oauth_token_secrets] <oauth_token> = <oauth_token_secret>
      iii. [oauth_token_users] <oauth_token> = <username>

      The format I've used above is [section name] followed by how the keys and values for that section will look on subsequent lines. The secrets are a way for the consumer to prove that it owns the corresponding consumer key or access token. The mapping of auth tokens to usernames is a way to specify which user/roles to give to a consumer with a given access token.

      In the future we will also store tokens in the user database (see below).

      3. OAuth replication. I've extended the JSON sent via POST when initiating a replication as follows:

      {
      source: {
      url: <url>,
      auth: {
      oauth:

      { consumer_key: <oauth_consumer_key>, consumer_secret: <oauth_consumer_secret>, token_secret: <oauth_token_secret>, token: <oauth_token> }

      }
      },
      target: /* same syntax as source, or string for a URL with no auth info, or string for local database name */
      }

      4. This patch also includes cookie-authentication support to CouchDB. I've covered this here: http://www.jasondavies.com/blog/2009/05/27/secure-cookie-authentication-couchdb/

      The cookie-authentication branch is being used on a couple of live sites and the branch has also been worked on by jchris and benoitc. As well as cookie auth it includes the beginnings of support for a per-node user database, with APIs for creating/deleting users etc.

      1. oauth.3.patch
        125 kB
        Jason Davies
      2. oauth.2.patch
        127 kB
        Jason Davies
      3. oauth.1.diff
        127 kB
        Jason Davies

        Activity

          People

          • Assignee:
            Unassigned
            Reporter:
            Jason Davies
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development