badarg jwt_auth required_claims with param

Description

I receive an unknown_error : badarg from erlang:list_to_existing_atom/1 when I try to authenticate using a JWT token and [jwt_auth] required_claims includes a tuple with param, like exp, iss {"yourissuername"} (from the example).

Steps to Reproduce

1. configure couchdb to accept jwt auth
   [chttpd] authentication_handlers = {chttpd_auth, jwt_authentication_handler}
2. configure required claims to include a tuple claim, like the
   example
   [jwt_auth] required_claims = exp, {iss, "IssuerNameHere"}
3. make a request to _session bearing a JWT token.
   (doesn't really matter which token, the error happens before actual validation afaict)

Expected Behaviour

To get authenticated (or not, but not an unknown error)

Your Environment

{"couchdb":"Welcome","version":"3.1.1","git_sha":"ce596c65d","uuid":"c4d21e152a90a6cf779e046c9ddb012b","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

• CouchDB version used: 3.1.1
• Browser name and version: n/a
• Operating system and version: official docker image

Additional Context

It happens somewhere here. (In the main branch, that code looks different, with a regex supporting tuples.)

stack trace

[error] 2020-10-29T13:51:27.130984Z nonode@nohost <0.19228.0> 9177353606 req_err(824051426) unknown_error : badarg [
	<<"erlang:list_to_existing_atom/1">>,
	<<"couch_httpd_auth:-get_configured_claims/0-lc$^0/1-0-/1 L216">>,
	<<"couch_httpd_auth:-get_configured_claims/0-lc$^0/1-0-/1 L216">>,
	<<"couch_httpd_auth:jwt_authentication_handler/1 L194">>,
	<<"chttpd:authenticate_request/2 L532">>,
	<<"chttpd:process_request/1 L304">>,
	<<"chttpd:handle_request_int/1 L244">>,
	<<"mochiweb_http:headers/6 L150">>
]

I realise now, after typing everything, that the docs I linked are for main, and tuples in required_claims were just not yet merged in 3.1.1. So perhaps this now turns into the question: how then do I provide which iss claim I expect?

[mtenrero]

I can confirm and reproduce the error on 3.1.1. with a present iss claim configured with the JWT issuer

[error] 2020-11-02T02:32:04.825057Z couchdb@127.0.0.1 <0.3213.0> adf7b85b19 req_err(2423103563) unknown_error : badarg
    [<<"erlang:list_to_existing_atom/1">>,<<"couch_httpd_auth:-get_configured_claims/0-lc$^0/1-0-/1 L216">>,<<"couch_httpd_auth:jwt_authentication_handler/1 L194">>,<<"chttpd:authenticate_request/2 L532">>,<<"chttpd:process_request/1 L304">>,<<"chttpd:handle_request_int/1 L244">>,<<"mochiweb_http:headers/6 L150">>,<<"proc_lib:init_p_do_apply/3 L247">>]
[notice] 2020-11-02T02:32:04.825317Z couchdb@127.0.0.1 <0.3213.0> adf7b85b19

{
  "error": "unknown_error",
  "reason": "badarg",
  "ref": 2423103563
}

[mtenrero]

I've discovered this issue it's already fixed with this #3165 which it's already merged on 3.x branch.

I've compiled from source and I can confirm the JWT authentication with ISS required claim it's working as expected.

So in the next release, it will be completely usable. For the moment if you need a CouchDB version with JWT auth and iss required claim, I'd suggest to compile from 3.x source branch.

[NBroomfield]

+1 This is causing me issue, spent ages setting it all up, auth_handlers, converting DER to PEM, setting iss claim, now this :-(

Any idea when the next patch (e.g. 3.1.2) release will be?

Thanks

Neil

[broomfn]

For anyone else with this issue, if it helps I've cherry picked #3165 into 3.1.1 and created a new fork here:

https://github.com/RGS-IT-Development/couchdb/tree/3.1.1.1

I've also built a docker image here:

https://github.com/orgs/RGS-IT-Development/packages/container/package/couchdb

I can confirm this works for my environment.

[wohali]

FYI 3.2 is being prepared right now and should release in June 2021.

[mtenrero]

Also this PR apache/couchdb-config#32 should be taken into account in order to allow kid fields with equal signs.

[broomfn]

@mtenrero good find, our JWT issuer rotates it's keys so we don't load them in the .ini file we dynamically push them to the couchdb config URL (https://docs.couchdb.org/en/latest/api/server/configuration.html), so not sure this is an issue for us?, but maybe for others, thanks!