Secure transfer of user credentials is a very delicate matter.
If we weren’t looking at third-party devices, in most cases SSL is best started from then on, as it has broad support for all the tools you could use. The SSL certificate provides not only encryption (even self-signed), but also insurance, which the user requested from the right resource. The latter option is also worth highlighting if you care about server security. The main disadvantage of using SSL is a decrease in performance (depending on the algorithm used), since the server needs to decrypt the data, and the client needs to verify the certificate in addition to the general communication procedures. You also need to pay money for a trusted certificate ( not always true ).
Using OAuth allows you to not disclose real user credentials and easily maintain access control from the server. In addition, you need a library that handles the OAuth 1.0 specification correctly, and if your platform skips it, you must implement it yourself. The optional OAuth provides data transfer, so it is designed to provide security for the MiTM case. That is actually all he does.
As you noted, SSL and OAuth have two different things: SSL helps to encrypt data at the transport level (TLS), while OAuth takes care of the disclosure of credentials in an insecure environment. They do not replace each other, but each of them can be a good addition to the others.
To configure SSL support for CouchDB, simply follow the guide. It is quite simple and easy to do. Please note that if there is some proxy server in front of CouchDB, it may be wise to configure SSL for it and proxy data on the local CouchDB instance via the normal HTTP protocol.
To configure OAuth, you must perform the following steps: 0. Verify that authentication_handlers have the option {couch_httpd_oauth, oauth_authentication_handler} for authentication_handlers in the [httpd] section for the default.ini configuration file:
[HTTPD] authentication_handlers = {couch_httpd_oauth, oauth_authentication_handler}, {couch_httpd_auth, cookie_authentication_handler}, {couch_httpd_auth, default_authentication_handler}
After that, you need to edit the local.ini file as follows:
- Configuring user privacy:
[oauth_consumer_secrets] example.org = sekr1t
- Assignment of token secrets:
[oauth_token_secrets] token1 = tokensekr1t
- Display tokens for existing CouchDB users:
[oauth_token_users] token1 = joe
It's all! If you have CouchDB version 1.2 or higher, you can also define OAuth credentials inside a user document inside the _users database:
{ "_id": "org.couchdb.user:joe", "type": "user", "name": "joe", "password_sha": "fe95df1ca59a9b567bdca5cbaf8412abd6e06121", "salt": "4e170ffeb6f34daecfd814dfb4001a73" "roles": ["foo", "bar"], "oauth": { "consumer_keys": { "example.org": "sekr1t", "consumerKey2": "key2Secret" }, "tokens": { "token1": "tokensekr1t", "token2": "token2Secret" } } }
Now that we have set up the OAuth credentials for our user joe, let's begin our replication. To allow CouchDB to use OAuth credentials, we need to expand the source or target fields, depending on which side will authorize our user:
{ "source": "mailbox", "target": { "url": "https://secure.example.org/mailbox", "auth": { "oauth": { "consumer_secret": "sekr1t", "consumer_key": "example.org", "token_secret": "tokensekr1t", "token": "token1" } } } }
and POST this data into the _replicate resource or create a document for the _replicator database. Replication will start from the local server to the remote secure.example.org using SSL encryption, and all operations will be performed for the remote user with the login joe .
Summing up: the combination of SSL and OAuth allows not only to protect the transmitted data (not only user credentials), but also to protect the target server, but also protects the real username and password from accidental disclosure of information, controls the sources of consumption (for example, if example.org will be compromised, we can remove his consumer token, but not force the user to change his password) and sign requests for additional protection against MiTM attacks.
UPDATE . In your case, the usual SSL certificate procedures are approved: you will need to create personal certificates signed by yourself and allow clients to set up for further work with your CouchDB. The only thing required of CouchDB is to verify the certificates before connecting to the process. But keep in mind that the usual personal installation of an SSL certificate may not be trivial , especially for mobile clients.
Speaking of the OAuth side, CouchDB can use the RSA-SHA1 auth method, which uses some kind of personal certificate for privacy. However, first you need to fix the sources to unlock this method - it is disabled by default.