backend/tests/conftest.py, line 162-177 (link)

Expired refresh token fixture bypasses Redis JTI registration

The expired_refresh_token fixture builds a JWT directly via jwt.encode with a hardcoded jti ("expired-test-jti") but never calls redis_client.setex(f"refresh-jti:expired-test-jti", ...). As a result, the test test_refreshing_oauth_token_expired_refresh_token silently validates two failure modes simultaneously:

1. The expiry check (now > claims["exp"]) fires first → raises OAuthCredentialsException → 401 ✓
2. If the expiry check were ever removed or reordered, the getdel(f"refresh-jti:expired-test-jti") would return None ≠ b"valid" → also 401, masking the regression.

The test title says "expired refresh token", but the fixture would produce the same 401 result even on a valid-expiry token because the JTI is never in Redis. This means the test doesn't purely verify expiry-based rejection.

A cleaner approach is to use oauth_handler.create_refresh_token(...) directly (which does register the JTI in Redis) with a very short but positive delta, then manipulate time in the assertion, or to store the JTI explicitly so the test isolates exactly one rejection path:

@pytest.fixture
def expired_refresh_token(admin_user: User) -> str:
    expire = int((datetime.now(timezone.utc) + timedelta(seconds=-1)).timestamp())
    jti = "expired-test-jti"
    redis_client.setex(f"refresh-jti:{jti}", 60, "valid")   # register so only expiry rejects

    return jwt.encode(
        {"alg": ALGORITHM},
        {
            "sub": admin_user.username,
            "iss": "romm:oauth",
            "scopes": " ".join(admin_user.oauth_scopes),
            "type": "refresh",
            "jti": jti,
            "exp": expire,
        },
        oct_key,
    )

backend/tests/endpoints/test_oauth.py, line 17-31 (link)

New refresh_token and refresh_expires response fields not asserted

This PR adds refresh_token and refresh_expires to every token response, including the refresh_token grant flow. The pre-existing test_refreshing_oauth_token_basic test only checks access_token, token_type, and expires — the two newly-added fields go completely unverified.

The new rotation test (test_refresh_token_rotation_invalidates_old_token) does assert first_body["refresh_token"] incidentally, but test_refreshing_oauth_token_basic is the canonical "happy path" test and should be updated to assert both new fields:

(You'll need to import REFRESH_TOKEN_EXPIRE_DAYS from endpoints.auth alongside ACCESS_TOKEN_EXPIRE_SECONDS.)

backend/handler/auth/base_handler.py, line 271-292 (link)

Sub-second positive expires_delta silently truncates Redis TTL to 0

The guard on line 272 correctly rejects <= timedelta(0), but the Redis SETEX call on line 286 computes:

int(expires_delta.total_seconds())

For any positive delta shorter than 1 second (e.g., timedelta(milliseconds=500) → total_seconds() = 0.5), int(...) truncates to 0. Redis's SETEX command rejects a TTL of 0 with ERR invalid expire time in 'setex', raising a redis.exceptions.ResponseError at runtime even though the guard passed.

The production token lifetime (timedelta(days=7)) is well above this threshold, so it won't be triggered in normal usage. However, it is a silent footgun for any future caller that passes a very short delta (e.g., in new test scenarios). The guard should be updated to check the truncated integer value rather than the raw timedelta:

ttl_seconds = int(expires_delta.total_seconds())
if ttl_seconds <= 0:
    raise ValueError("expires_delta must result in a positive TTL (>= 1 second) for refresh tokens")

Then pass ttl_seconds directly to redis_client.setex(...) so the computed value is only evaluated once and the guard always matches what Redis actually receives.