3.9. Authentication and Authorization¶
3.9.1. Server Administrators¶
- [admins]¶
Changed in version 3.0.0: CouchDB requires an admin account to start. If an admin account has not been created, CouchDB will print an error message and terminate.
CouchDB server administrators and passwords are not stored in the
_users
database, but in the last [admins]
section that CouchDB
finds when loading its ini files. See :config:intro for details on config
file order and behaviour. This file (which could be something like
/opt/couchdb/etc/local.ini
or
/opt/couchdb/etc/local.d/10-admins.ini
when CouchDB is installed from
packages) should be appropriately secured and readable only by system
administrators:
[admins]
;admin = mysecretpassword
admin = -hashed-6d3c30241ba0aaa4e16c6ea99224f915687ed8cd,7f4a3e05e0cbc6f48a0035e3508eef90
architect = -pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000
Administrators can be added directly to the [admins]
section, and when
CouchDB is restarted, the passwords will be salted and encrypted. You may
also use the HTTP interface to create administrator accounts; this way,
you don’t need to restart CouchDB, and there’s no need to temporarily store
or transmit passwords in plaintext. The HTTP
/_node/{node-name}/_config/admins
endpoint supports querying, deleting
or creating new admin accounts:
GET /_node/nonode@nohost/_config/admins HTTP/1.1
Accept: application/json
Host: localhost:5984
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 196
Content-Type: application/json
Date: Fri, 30 Nov 2012 11:37:18 GMT
Server: CouchDB (Erlang/OTP)
{
"admin": "-hashed-6d3c30241ba0aaa4e16c6ea99224f915687ed8cd,7f4a3e05e0cbc6f48a0035e3508eef90",
"architect": "-pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000"
}
If you already have a salted, encrypted password string (for example, from an old ini file, or from a different CouchDB server), then you can store the “raw” encrypted string, without having CouchDB doubly encrypt it.
PUT /_node/nonode@nohost/_config/admins/architect?raw=true HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 89
Host: localhost:5984
"-pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000"
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 89
Content-Type: application/json
Date: Fri, 30 Nov 2012 11:39:18 GMT
Server: CouchDB (Erlang/OTP)
"-pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000"
Further details are available in security, including configuring the work
factor for PBKDF2
, and the algorithm itself at
PBKDF2 (RFC-2898).
Changed in version 1.4: PBKDF2 server-side hashed salted password support added, now as a
synchronous call for the _config/admins
API.
3.9.2. Authentication Configuration¶
- [chttpd]¶
- require_valid_user¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd] section
When this option is set to
true
, no requests are allowed from anonymous users. Everyone must be authenticated.[chttpd] require_valid_user = false
- require_valid_user_except_for_up¶
When this option is set to
true
, no requests are allowed from anonymous users, except for the/_up
endpoint. Everyone else must be authenticated.[chttpd] require_valid_user_except_for_up = false
- [chttpd_auth]¶
Changed in version 3.2: These options were moved to [chttpd_auth] section: authentication_redirect, timeout, auth_cache_size, allow_persistent_cookies, iterations, min_iterations, max_iterations, secret, users_db_public, x_auth_roles, x_auth_token, x_auth_username, cookie_domain, same_site.
- allow_persistent_cookies¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
When set to
true
, CouchDB will set the Max-Age and Expires attributes on the cookie, which causes user agents (like browsers) to preserve the cookie over restarts.[chttpd_auth] allow_persistent_cookies = true
- cookie_domain¶
Added in version 2.1.1.
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
Configures the
domain
attribute of theAuthSession
cookie. By default thedomain
attribute is empty, resulting in the cookie being set on CouchDB’s domain.[chttpd_auth] cookie_domain = example.com
- same_site¶
Added in version 3.0.0.
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
When this option is set to a non-empty value, a
SameSite
attribute is added to theAuthSession
cookie. Valid values arenone
,lax
orstrict
.:[chttpd_auth] same_site = strict
- auth_cache_size¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
Number of User Context Object to cache in memory, to reduce disk lookups.
[chttpd_auth] auth_cache_size = 50
- authentication_redirect¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
Specifies the location for redirection on successful authentication if a
text/html
response is accepted by the client (via anAccept
header).[chttpd_auth] authentication_redirect = /_utils/session.html
- hash_algorithms¶
Added in version 3.3.
Note
Until CouchDB version 3.3.1, Proxy Authentication used only the hash algorithm
sha1
as validation ofX-Auth-CouchDB-Token
.Sets the HMAC hash algorithm used for cookie and proxy authentication. You can provide a comma-separated list of hash algorithms. New cookie sessions or session updates are calculated with the first hash algorithm. All values in the list can be used to decode the cookie session and the token
X-Auth-CouchDB-Token
for Proxy Authentication.[chttpd_auth] hash_algorithms = sha256, sha
Note
You can select any hash algorithm the version of erlang used in your CouchDB install supports. The common list of available hashes might be:
sha, sha224, sha256, sha384, sha512
To retrieve a complete list of supported hash algorithms you can use our
bin/remsh
script and retrieve a full list of available hash algorithms withcrypto:supports(hashs).
or use the _node/{node-name}/_versions endpoint to retrieve the hashes.Warning
We do not recommend using the following hash algorithms:
md4, md5
- iterations¶
Added in version 1.3.
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
The number of iterations for password hashing by the PBKDF2 algorithm. A higher number provides better hash durability, but comes at a cost in performance for each request that requires authentication. When using hundreds of thousands of iterations, use session cookies, or the performance hit will be huge. (The internal hashing algorithm is SHA1, which affects the recommended number of iterations.)
[chttpd_auth] iterations = 10000
- min_iterations¶
Added in version 1.6.
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
The minimum number of iterations allowed for passwords hashed by the PBKDF2 algorithm. Any user with fewer iterations is forbidden.
[chttpd_auth] min_iterations = 100
- max_iterations¶
Added in version 1.6.
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
The maximum number of iterations allowed for passwords hashed by the PBKDF2 algorithm. Any user with greater iterations is forbidden.
[chttpd_auth] max_iterations = 100000
- password_regexp¶
Added in version 3.2.
A list of Regular Expressions to check new/changed passwords. When set, new user passwords must match all RegExp in this list.
A RegExp can be paired with a reason text:
[{"RegExp", "reason text"}, ...]
. If a RegExp doesn’t match, its reason text will be appended to the default reason ofPassword does not conform to requirements.
[couch_httpd_auth] ; Password must be 10 chars long and have one or more uppercase and ; lowercase char and one or more numbers. password_regexp = [{".{10,}", "Min length is 10 chars."}, "[A-Z]+", "[a-z]+", "\\d+"]
- proxy_use_secret¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
When this option is set to
true
, thechttpd_auth/secret
option is required for Proxy Authentication.[chttpd_auth] proxy_use_secret = false
- public_fields¶
Added in version 1.4.
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
A comma-separated list of field names in user documents (in
couchdb/users_db_suffix
) that can be read by any user. If unset or not specified, authenticated users can only retrieve their own document.[chttpd_auth] public_fields = first_name, last_name, contacts, url
Note
Using the
public_fields
allowlist for user document properties requires setting thechttpd_auth/users_db_public
option totrue
(the latter option has no other purpose):[chttpd_auth] users_db_public = true
- secret¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
The secret token is used for Proxy Authentication and for Cookie Authentication.
[chttpd_auth] secret = 92de07df7e7a3fe14808cef90a7cc0d91
- timeout¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
Number of seconds since the last request before sessions will be expired.
[chttpd_auth] timeout = 600
- users_db_public¶
Added in version 1.4.
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
Allow all users to view user documents. By default, only admins may browse all users documents, while users may browse only their own document.
[chttpd_auth] users_db_public = false
- x_auth_roles¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
The HTTP header name (
X-Auth-CouchDB-Roles
by default) that contains the list of a user’s roles, separated by a comma. Used for Proxy Authentication.[chttpd_auth] x_auth_roles = X-Auth-CouchDB-Roles
- x_auth_token¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
The HTTP header name (
X-Auth-CouchDB-Token
by default) containing the token used to authenticate the authorization. This token is an HMAC-SHA1 created from thechttpd_auth/secret
andchttpd_auth/x_auth_username
. The secret key should be the same on the client and the CouchDB node. This token is optional if the value of thechttpd_auth/proxy_use_secret
option is nottrue
. Used for Proxy Authentication.[chttpd_auth] x_auth_token = X-Auth-CouchDB-Token
- x_auth_username¶
Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section
The HTTP header name (
X-Auth-CouchDB-UserName
by default) containing the username. Used for Proxy Authentication.[chttpd_auth] x_auth_username = X-Auth-CouchDB-UserName
- upgrade_hash_on_auth¶
Added in version 3.4.
Upgrade user auth docs during the next successful authentication using the current password hashing settings.
[chttpd_auth] upgrade_hash_on_auth = false
- [jwt_auth]¶
- required_claims¶
This parameter is a comma-separated list of additional mandatory JWT claims that must be present in any presented JWT token. A 404 Not Found is sent if any are missing.
[jwt_auth] required_claims = exp,iat
- roles_claim_name¶
Warning
roles_claim_name
is deprecated in CouchDB 3.3, and will be removed later. Please migrate toroles_claim_path
.If presented, it is used as the CouchDB user’s roles list as long as the JWT token is valid. The default value for
roles_claim_name
is_couchdb.roles
.Note
Values for
roles_claim_name
can only be top-level attributes in the JWT token. Ifroles_claim_path
is set, thenroles_claim_name
is ignored!Let’s assume, we have the following configuration:
[jwt_auth] roles_claim_name = my-couchdb.roles
CouchDB will search for the attribute
my-couchdb.roles
in the JWT token.{ "my-couchdb.roles": [ "role_1", "role_2" ] }
- roles_claim_path¶
Added in version 3.3.
This parameter was introduced to overcome disadvantages of
roles_claim_name
, because it is not possible withroles_claim_name
to map nested role attributes in the JWT token.Note
If
roles_claim_path
is set, thenroles_claim_name
is ignored!Now it is possible the read a nested roles claim from JWT tokens into CouchDB. As always, there is some theory at the beginning to get things up and running. Don’t get scared now, it’s really short and easy. Honestly!
There are only two characters with a special meaning. These are
.
for nesting json attributes and\.
to skip nesting
That’s it. Really.
Let’s assume there is the following data-payload in the JWT token:
{ "resource_access": { "security.settings": { "account": { "roles": [ "manage-account", "view-profile" ] } } } }
Now, let’s define the config variable
roles_claim_path
for this example. It should look like this:roles_claim_path = resource_access.security\.settings.account.roles
If an attribute has a
.
in the key likesecurity.settings
, you have to escape it in the config parameter with\.
. If you use a.
then it gets interpreted as a nested sub-key. Let’s illustrate the behavior with a second example. There is the following config parameter forroles_claim_name
(by the way it was the default value if you didn’t configured it):roles_claim_name = _couchdb.roles
Note
CouchDB doesn’t set any default or implicit value for
roles_claim_path
.To migrate from
roles_claim_name
toroles_claim_path
you need to change the parameter name and escape the.
to prevent CouchDB to read this as a nested JSON key.roles_claim_path = _couchdb\.roles
Let’s assume your JWT token have the following data-payload for your couchdb roles claim:
{ "_couchdb.roles": [ "accounting-role", "view-role" ] }
If you did everything right, the response from the
_session
endpoint should look something like this:GET /_session HTTP/1.1 Host: localhost:5984 Authorization: Bearer <JWT token>
HTTP/1.1 200 OK Content-Type: application/json
{ "ok": true, "userCtx": { "name": "1234567890", "roles": [ "accounting-role", "view-role" ] }, "info": { "authentication_handlers": [ "jwt", "proxy", "cookie", "default" ], "authenticated": "jwt" } }
That’s all, you are done with the migration from
roles_claim_name
toroles_claim_path
Easy, isn’t it?
- [chttpd_auth_lockout]¶
- mode¶
When set to
off
(the default), CouchDB will not track repeated authentication failures.When set to
warn
, CouchDB will log a warning when repeated authentication failures occur for a specific user and client IP address.When set to
enforce
, CouchDB will will reject requests with a 403 status code if repeated authentication failures occur for a specific user and client IP address.[chttpd_auth_lockout] mode = enforce
- threshold¶
When
threshold
(default5
) number of failed authentication requests happen within the samemax_lifetime
period, CouchDB will lock out further authentication attempts for the rest of themax_lifetime
period ifmode
is set toenforce
.[chttpd_auth_lockout] threshold = 5
- max_objects¶
The maximum number of username+IP pairs that CouchDB will track, to limit memory usage. Defaults to
10,000
. Changes to this setting are only picked up at CouchDB start or restart time.[chttpd_auth_lockout] max_objects = 10000
- max_lifetime¶
The maximum duration of the lockout period, measured in milliseconds. Changes to this setting are only picked up at CouchDB start or restart time.
[chttpd_auth_lockout] max_lifetime = 300000