email_verified Claim in an OpenID Connect ID Token

The specification is careful about what the boolean asserts: true means the issuer took affirmative steps to ensure the address was controlled by the end user at the time of verification, and that it may not still be. It is a statement about the past made by the issuer, not a live check, and how rigorous the verification was is entirely up to that issuer.

The attack it prevents is straightforward. If an application links accounts by email address alone, anyone who can persuade a provider to issue a token containing somebody else's address takes over the matching local account. Some providers historically allowed unverified addresses to be set freely on self service signups, which turned an unchecked link into an account takeover with no exploit code involved.

So the rule is simple to state: never link, merge or elevate an account on an email address unless email_verified is true in the token you are holding right now, from an issuer you decided in advance to trust for that address. A previously stored value is not enough, since the address may have changed since, and a claim from an unexpected issuer is not evidence about a domain it does not control.

There is also a decoding trap. The claim is defined as a JSON boolean, but some deployments emit the string true instead, and in a language with loose truthiness both look positive while only one is correct. The decoder renders the payload as parsed JSON with syntax highlighting, so a real boolean and a quoted string are visibly different, which makes this a quick thing to check.