Port Python use of jwcrypto to new Rust library

[mmastrac]

This migrates all Python code from jwcrypto to gel-jwt.

As part of the work, the auth-ext code is reorganized a bit so all the token types are managed centrally and given common names.

Server notes:

• The allow and denylist for the JWT claims are loaded into the JWKSet's default_validation_context and checked internally at token validation time. These are still reloadable and can be updates as files on disk change.
• Both PEM and JSON JWK json files are supported. If JWK auto-generation is enabled and the JWK filename ends in .json, a JSON-format JWK will be created (along with a key ID) allowing for eventual key rotation.

auth_ext notes

• We start to cache remote JWKSets (10 mins) as those are unlikely to change often and it's likely they will cause HTTP failures at scale.
• Each JWT type used by auth_ext has its own Python token type and derived HKDF key to ensure keys can never accidentally be used across auth_ext token domains (most keys already had this).

Additional changes:

• Token expiration and allowlists are checked within the new gel-jwt library so we can remove all of that handling internally.
• auth_ext testcases were refactored a bit and some common code was pulled out into generate_and_serve_jwk

[scotttrinh]

gorgeous 🏆

[scotttrinh]

Why are we setting an nbf here? Maybe related to removing the iat check?

[mmastrac]

This is a safeguard to prevent tokens issued in the future from being used for extended periods of time. I noticed that the Rust library doesn't check that iat is in the past, so it prevents tokens from the future from being used.

It's pretty unlikely you could trick a server into issuing a token from the future, but if you did you could potentially have a long-lived token.

[scotttrinh]

I think I specifically wanted to understand why we removed the iat handling from the email verification JWT. I don't recall 100% of the details here, but I remember switching to iat from exp for a specific reason. I'll see if I can resurrect it. Something about handling old verification emails (someone forgot to verify, waited too long, and tried to verify again) and still being able to send a refreshed one.

[mmastrac]

Oh, yes -- there's a skip_expiration_check on the verification token JWT method that explicitly ignores the expiry for the case of resending validation emails.

So basically we still check the signature in that case, but we ignore the timestamps. That's the only case I could find where that was required.

We might want to limit how far we extend the expiry to resend an email (maybe 30 days?) but for now I believe it acts the same way as before.

[scotttrinh]

Yeah, I think the iat-related logic was explicitly to still limit the validity to some reasonable time frame without using an expiration time. I'll take another look at the old logic and do a little bit of research from back when I implemented this to be sure. I'm not sure I trust that there is an existing test for this case, so might be worth writing one in the course of figuring out what the actual behavior is meant to be.

[mmastrac]

I looked at the old source -- it appears that we were using iat to do a pseudo 24-hour expiration without an 'exp' token. I put all of the expiration times into constants in the jwt module and confirmed that they were the same as the previous.

[scotttrinh]

There was some explicit reason I avoided an exp time back when I wrote it, but I can't quite recall. When I get a little space to go back into the history a bit, I'll give a final approval on this. I'd rather keep the existing behavior to not block landing this, but I'm also fine with sitting on it to be sure.