Add configurable issuer/audience validation with dynamic claim support#957
Add configurable issuer/audience validation with dynamic claim support#957diegocastrum wants to merge 9 commits intojazzband:masterfrom
Conversation
- Add `ISS_CLAIM` and `ALLOWED_ISSUERS` settings for issuer configuration - Implement `set_iss()` and `verify_iss()` methods in `Token` class - Add issuer verification in `Token.verify()` when configured - Call `set_iss()` in `TokenRefreshSerializer` during token rotation - Comment out issuer parameter from `TokenBackend` (WIP) - Disable PyJWT's built-in issuer validation in `decode()` This enables tokens to have dynamic issuers based on request context while maintaining backward compatibility with static `ISSUER` setting. Validation supports three modes: - Static issuer (`ISSUER` setting) - Whitelist validation (`ALLOWED_ISSUERS` setting) - Dynamic issuers (no issuer validation beyond format checks) Note: `TokenBackend` issuer handling still needs refactoring to fully support the dynamic issuer workflow without double-decoding. Fixes jazzband#899
…port - add `ISSUER_VALIDATION` setting (static/dynamic) defaulting to static PyJWT enforcement - pass issuer to `TokenBackend/PyJWT` only in static mode; skip in dynamic mode to allow per-token issuers Add support for `aud` (audience) and `iss` (issuer) claims in tokens Fixes jazzband#899
- add `AUDIENCE_VALIDATION` setting (static/dynamic) and wire backend to skip PyJWT audience checks in dynamic mode - allow `Token.verify_aud` to accept per-token audiences when config is unset and dynamic mode is enabled - expose backend `verify_aud`/`verify_iss` flags and document the new setting Add support for `aud` (audience) and `iss` (issuer) claims in tokens Fixes jazzband#899
|
@Andrew-Chen-Wang would you mind taking a look when you have time? Would appreciate a quick review or guidance on how to move forward |
Andrew-Chen-Wang
left a comment
There was a problem hiding this comment.
thanks for these changes. left some comments. have more to come pending your thoughts
| "AUDIENCE_VALIDATION": "static", | ||
| "ISSUER": None, | ||
| "ISSUER_VALIDATION": "static", | ||
| "ISS_CLAIM": "iss", |
There was a problem hiding this comment.
Would be great to be consistent at least in the settings saying ISSUER_CLAIM. The code can say iss for short no prob.
| api_settings.AUDIENCE, | ||
| api_settings.ISSUER, | ||
| api_settings.AUDIENCE if api_settings.AUDIENCE_VALIDATION == "static" else None, | ||
| api_settings.ISSUER if api_settings.ISSUER_VALIDATION == "static" else None, |
There was a problem hiding this comment.
is this none because ALLOWED_ISSUERS is there?
| "ISSUER": None, | ||
| "ISSUER_VALIDATION": "static", | ||
| "ISS_CLAIM": "iss", | ||
| "ALLOWED_ISSUERS": None, |
There was a problem hiding this comment.
Can you modify __check_user_settings in this file to make sure the user's settings look correct? I feel like a lot of settings combinations can be incorrect here.
| "ISSUER": None, | ||
| "ISSUER_VALIDATION": "static", | ||
| "ISS_CLAIM": "iss", | ||
| "ALLOWED_ISSUERS": None, |
There was a problem hiding this comment.
I feel like ISSUER could just be a list instead. If it's a list, we'll just automatically omit the iss key because the RFC doesn't allow lists in the first place (some implementations use it, but let's not since we could break some external/third-party apps)
This pull request introduces flexible and configurable validation for the JWT audience (
aud) and issuer (iss) claims in both token generation and verification. It allows projects to choose between strict/static validation (using fixed values from settings) or dynamic validation (accepting values from incoming tokens and validating them according to custom logic). The changes include new settings, backend logic updates, token claim handling, and comprehensive tests for these behaviors.Audience and Issuer Validation Improvements:
AUDIENCE_VALIDATIONandISSUER_VALIDATION, allowing control over whether audience and issuer are validated statically (default, using configured values) or dynamically (accepting values from tokens and validating them in code). [1] [2]TokenBackendto respect the new validation modes, passing or omittingaudienceandissuerto PyJWT as appropriate. [1] [2] [3] [4]Token Claim Handling:
set_iss,set_aud,verify_iss, andverify_audmethods in theTokenclass to support dynamic/static claim population and validation, including support for an allowed issuers whitelist. [1] [2]issandaudclaims during creation, and that these claims are validated according to the selected mode. [1] [2]Documentation Updates:
Testing Enhancements:
Closes #899