AsyncOpenIDMixin.parse_id_token: return None when id_token is absent, matching the sync client - #924

OpenIDMixin.parse_id_token starts with a guard the async version doesn't have:

if "id_token" not in token:
    return None

So the same call returns None on the sync client and raises KeyError: 'id_token' on the async one. The first commit adds it.

The sync test suite already asserted the None case (test_flask/test_user_mixin.py), and the async suite never did, which is how the two drifted apart. That assertion is mirrored across.

The second commit changes a test. That needs explaining.

Adding the guard means a token without an id_token now returns early, before load_server_metadata(). That exposed test_runtime_error_fetch_jwks_uri, which calls:

await client.parse_id_token(req, token)

The signature is (token, nonce). That call uses the old (request, token) order, and it is the only one of eight sites that still does. The test passed because the RuntimeError was raised before anything read the misplaced arguments, so the stale call never mattered. With the guard in place the request object goes in as token, has no id_token, and returns None before the error can happen.

I changed that call to (token, nonce="n") so it matches the rest, and dropped the now-unused request object. It asserts the same RuntimeError path, now with a valid token.

test_starlette/test_user_mixin.py goes from 4 passing with one relying on that stale call to 4 passing without it. The sync suite is untouched and still passes.

I ran the starlette and flask client suites. Not the django ones, which need dependencies I don't have installed.