authlib icon indicating copy to clipboard operation
authlib copied to clipboard

Migration to joserfc

Open azmeuk opened this issue 7 months ago • 4 comments

Authlib will dump the authlib.jose module in favor of joserfc.

Here is the migration guide.

azmeuk avatar Apr 30 '25 07:04 azmeuk

Are the examples in the migration guide actually correct?

From the docs, it sounds like the old jwt.decode() is unsafe by default and you have to manually call token.validate() on the result. And the new example looks like it only verifies that iss is present with some specific value but doesn't look at any of RFC-mandated registered claims?

lava avatar Nov 04 '25 13:11 lava

I think the docs are correct in the sense of demonstrating how we can validate token claims using jwt.JWTClaimsRegistry . The RFC7519 time-based claims ('iat', 'nbf' 'exp') are validated automatically by the claims registry, see here.

Maybe the documentation examples should encourage good practice by presenting an example that is also checking the 'sub' and 'aud' claims?

bjmc avatar Nov 04 '25 15:11 bjmc

Maybe this is just an issue with the documentation and not with the guide then, but it feels like the two contradict each other. The comment for the old example says:

# Decode and validate the token's claims
token = jwt.decode(s, key, claims_options)

But the example code in the docs strongly implies that claims are not validated, otherwise what would be the point of calling .validate() separately?

>>> claims = jwt.decode(s, public_key)
>>> print(claims)
{'iss': 'Authlib', 'sub': '123', ...}
>>> print(claims.header)
{'alg': 'RS256', 'typ': 'JWT'}
>>> claims.validate()

For the new example, it's good that exp, etc. are validated by default, that wasn't clear to me from reading the documentation.

Maybe the documentation examples should encourage good practice by presenting an example that is also checking the 'sub' and 'aud' claims?

I'm not sure about the sub claim, but the aud claim would absolutely make sense to check, since this is an example that's likely to be copy/pasted by many users who are new to the library. And "good practice" maybe underselling it a bit, rejecting invalid audiences is actually required by the RFC and forgetting to check the audience in production code would be a pretty serious security issue.

lava avatar Nov 10 '25 17:11 lava

joserfc has documentation for the default validators: https://jose.authlib.org/en/guide/jwt/#default-validators

lepture avatar Nov 28 '25 10:11 lepture