Extending JWT claims validation to support other claims
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- erlang
- Domain
- authentication, security
Research direction
Start with src/jwtf/src/jwtf.erl, especially the claim checks referenced at line 45, and review how required_claims is parsed. The change is complete when a configuration such as required_claims = exp, {aud, "my-application"} validates aud for existence and the supplied value, while supporting other provided claims without unknown_checks.
Written by the indexing model from the issue text.
Description
Based on source, I understand only limited number of JWT claims can be validated. Trying to validate other claims result in error unknown_checks.
I would like to ask for introducing validation any provided claim.
In my case, I use an SSO of a huge Organisation, where many users can define their own applications/clients (signed with same SSO key). Without validating aud, anyone could create another application with roles that my CouchDB instance accepts.
Desired Behaviour
When provided a config like below, the claim aud should be verified: both if it exists and if it matched provided my-application value.
required_claims = exp, {aud, "my-application"}
I believe it's worth allowing such a validation for any custom claim (only to check existence and value matching, if provided).
Possible Solution
I believe the source should not limit the check only to claims specified in line 45. There could be a function providing a "general" claim check, no matter what it is exactly.
- Dominant language
- Erlang
- Stars
- 7k
- Forks
- 1.1k
- Avg merge
- 1d 23m
- Merged PRs (30d)
- 30
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/couchdb
-
Fix: Warning: 'catch ...' is deprecated; please use 'try ... catch ... end' insteadPossibly taken @devx-arjun claimed this 3 days ago. Openbeginner-friendly build chore patches-welcome
Difficulty 4/5 3-5 days Newbie friendliness 45/100
apache/couchdb#6144 · 4 comments ·
Maintainers usually reply within 1 day
-
bug needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
apache/couchdb#6132 · 3 comments ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 45/100
apache/couchdb#6120 · 4 comments ·
Maintainers usually reply within 1 day
-
enhancement needs-triage
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
bug needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
Similar issues
-
[Bug] Four credential types still print their secrets in toStringPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
apache/rocketmq-dashboard#6091 ·
Maintainers usually reply within 4 days
-
area:auth bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ArchiveLabs/lenny#242 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/doris-flink-connector#707 ·