3.6. Authentication and Authorization

3.6.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.6.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

New in version 2.1.1.

Changed in version 3.2: moved from [couch_httpd_auth] to [chttpd_auth] section

Configures the domain attribute of the AuthSession cookie. By default the domain attribute is empty, resulting in the cookie being set on CouchDB’s domain.

[chttpd_auth]
cookie_domain = example.com
same_site

New 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 the AuthSession cookie. Valid values are none, lax or strict.:

[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 an Accept header).

[chttpd_auth]
authentication_redirect = /_utils/session.html
hash_algorithms

New in version 3.3.

Note

Until CouchDB version 3.3.1, Proxy Authentication used only the hash algorithm sha1 as validation of X-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 with crypto:supports(hashs). or use the _node/$node/_versions endpoint to retrieve the hashes.

Warning

We do not recommend using the following hash algorithms:

md4, md5
iterations

New 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

New 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

New 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

New 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 of Password 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, the chttpd_auth/secret option is required for Proxy Authentication.

[chttpd_auth]
proxy_use_secret = false
public_fields

New 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 the chttpd_auth/users_db_public option to true (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

New 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 the chttpd_auth/secret and chttpd_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 the chttpd_auth/proxy_use_secret option is not true. 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
[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 to roles_claim_path.

If presented, as a JSON array of strings, 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. If roles_claim_path is set, then roles_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

New in version 3.3.

This parameter was introduced to overcome disadvantages of roles_claim_name, because it is not possible with roles_claim_name to map nested role attributes in the JWT token.

Note

If roles_claim_path is set, then roles_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 like security.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 for roles_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 to roles_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 to roles_claim_path Easy, isn’t it?