GoogleOidcVerifier treats string "false" as a verified email claim

[ITSMERNB]

Summary

GoogleOidcVerifier currently checks the email_verified claim using Python truthiness:

if (
    not claims.get("email_verified")
    or claims.get("email") not in self._allowed_emails
):

A non-empty string such as "false" is truthy in Python, so it passes this check when the email is allowlisted.

Reproduction

Using the same condition as the current verifier:

email_verified=False   -> REJECT
email_verified="false" -> ACCEPT
email_verified=True    -> ACCEPT
email_verified=""      -> REJECT

The relevant implementation is in:

src/google/adk/cli/trigger_routes.py → GoogleOidcVerifier.

Expected behavior

The verifier should require an actual boolean True, for example:

claims.get("email_verified") is True

or otherwise validate the claim type explicitly before trusting it.

Context

This behavior was also publicly noted in google/adk-go commit 490f24cbc3aa7a9f9472175ba0d848530dc5b4f4, which states that ADK Python's truthiness check accepts non-empty strings including "false".

I have not identified a production Google-issued ID-token path that currently emits email_verified as the string "false", so I am reporting this as a correctness / defensive validation issue rather than claiming a demonstrated authentication bypass.

[vishal-bulbule]

Confirmed on current main (9a33588): GoogleOidcVerifier in src/google/adk/cli/trigger_routes.py still tests email_verified with truthiness, so the string values "false" and "true" and the integer 1 all pass when the email is on the allowlist. Google-issued ID tokens carry a JSON boolean, so this is a hardening change rather than a live bypass, but the check should match the claim type OpenID Connect defines.

I have the fix ready: require the claim to be exactly True, plus a parametrized test covering the three non-boolean values on both trigger endpoints. The test fails 6 of 6 on main and passes after the change. Opening the PR now unless someone is already on it.