安全傳輸用戶憑證是一個非常棘手的問題。
如果我們不看第三方，在大多數情況下，SSL是更好的開始方式，因爲它可以爲您使用的每種工具提供廣泛的支持。 SSL證書不僅提供加密（甚至是自簽名證書），還提供用戶要求正確資源的保險。如果您關心服務器安全性，最後一個選項也值得強調。 SSL使用的主要缺點是性能下降（根據使用的算法而有所不同），因爲服務器必須解密數據並且客戶端需要驗證除常用通信例程之外的證書。你也必須支付一些可信任的證書（not always true）。
使用OAuth允許不公開真實的用戶憑證並輕鬆維護其從服務器端的訪問控制。此外，您需要一些能正確處理OAuth 1.0規範的庫，如果您的平臺錯過了這些 - 您必須自行實施。在另外的OAuth提供傳輸數據簽名，所以它旨在爲MiTM案件安全。這實際上就是他所做的一切。
正如您所看到的，SSL和OAuth大約有兩種不同的東西：SSL有助於在傳輸級別（TLS）上加密數據，而OAuth會在非安全環境中關注證書披露。它們並不是相互替代的，但它們每個都可以與其他方面相比更好。
要爲CouchDB設置SSL支持，請按照documentation guide。這很簡單，容易做到。請注意，如果在CouchDB之前有一些代理服務器，那麼爲他設置SSL並通過常規HTTP協議將代理數據代理到本地CouchDB實例可能是明智之舉。
要設置的OAuth那裏需要進行下一個步驟： 0確保{couch_httpd_oauth, oauth_authentication_handler}處理程序是存在authentication_handlers選項[httpd]部的用於default.ini配置文件：
[httpd的] authentication_handlers = {couch_httpd_oauth，oauth_authentication_handler} {couch_httpd_auth，cookie_authentication_handler}，{couch_httpd_auth，default_authentication_handler}
之後，你需要編輯local.ini文件在明年方式：
- 設置消費的祕密：
[oauth_consumer_secrets]
example.org = sekr1t
- 設置令牌的祕密：
[oauth_token_secrets]
token1 = tokensekr1t
- 地圖標記來存在的CouchDB的用戶：
[oauth_token_users]
token1 = joe
就這樣！如果你的CouchDB 1.2或更高版本，你也可以定義用戶文檔中OAuth認證，內部_users數據庫：
{
"_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"
}
}
}
現在，當我們最好設置OAuth認證，爲我們的用戶喬，讓我們開始我們的複製。爲了讓CouchDB的使用OAuth認證，我們需要擴大source或target領域，這取決於哪一方將授權我們的用戶：
{
"source": "mailbox",
"target": {
"url": "https://secure.example.org/mailbox",
"auth": {
"oauth": {
"consumer_secret": "sekr1t",
"consumer_key": "example.org",
"token_secret": "tokensekr1t",
"token": "token1"
}
}
}
}
和POST這個數據_replicate資源或_replicator數據庫中創建的文檔。複製將使用SSL協議加密從本地服務器啓動到遠程secure.example.org，並且所有操作都將通過登錄joe用於遠程用戶。
總結：SSL和OAuth的結合使您不僅可以保護傳輸的數據（不僅是用戶證書）並確保目標服務器不被僞造，還可以保護真正的用戶登錄名和密碼免受意外泄露，控制消費者來源（例如，如果example.org將受到損害，我們只能刪除其消費者令牌，但不會強制用戶更改其密碼）並簽署請求以獲得針對MiTM攻擊的額外保護。
UPDATE：爲了您的情況，常規的SSL證書例程可以使用：您需要創建由您自己簽名的個人證書，並讓客戶端爲您的CouchDB進一步開展工作。從CouchDB方面唯一需要的是在處理連接之前驗證證書。但請注意，該定製個人SSL證書安裝可能是not trivial，尤其對於移動客戶端。
說到OAuth端，CouchDB 可能使用使用RSA-SHA1身份驗證方法，它使用某種個人證書作爲祕密。但是，您需要首先修補源以解鎖此方法 - 默認情況下它是禁用的。
**澄清**：我不是在尋找SSL傳輸安全性 - 對於[Apache HTTP]（http://httpd.apache.org/docs/2.2/ssl/ssl_faq） .html）和CouchDB。我正在尋找的是使用證書進行**身份驗證，類似於您可以在SSH中執行的操作。我使用OAuth看到的潛在問題：管理員可以完全訪問憑據（？）。使用證書方法，他不能模擬用戶，因爲私鑰不在管理員控制之下。 – stwissel 2013-02-28 16:31:21