Change:
} if a.usernameClaim == "email" { <del> // Check the email_verified claim to ensure the email is valid. </del> <ins> // If the email_verified claim is present, ensure the email is valid. </ins> // https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims <del> var emailVerified bool if err := c.unmarshalClaim("email_verified", &emailVerified); err != nil { return nil, false, fmt.Errorf("oidc: parse 'email_verified' claim: %v", err) } if !emailVerified { return nil, false, fmt.Errorf("oidc: email not verified") </del> <ins> if hasEmailVerified := c.hasClaim("email_verified"); hasEmailVerified { var emailVerified bool if err := c.unmarshalClaim("email_verified", &emailVerified); err != nil { return nil, false, fmt.Errorf("oidc: parse 'email_verified' claim: %v", err) } // If the email_verified claim is present we have to verify it is set to `true`. if !emailVerified { return nil, false, fmt.Errorf("oidc: email not verified") } </ins> } }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: Bug Report /kind bug What happened: This is related to I am trying to integrate Cloud Foundry UAA () with kubernetes using the OIDC flow and the JWT validation is failing on the kubernetes side with an error of emailverified is required. emailverified is not a required claim in the OIDC core spec From a security point of view emailverified is useful when Self Service is enabled which is true of internet identity providers User Provisioning workflow in almost all cases is admin driven and not self service and emailverified becomes an obsolete claim. With things as they stand today, this flow is not conducive to Enterprise Identity Providers. What you expected to happen: Authentication should succeeed How to reproduce it (as minimally and precisely as possible): Pass a JWT which is missing email_verified claim using the OIDC flow into kubernetes Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-12-16T03:15:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
It's not marked optional either, which was the original motivation for taking the safe route and assuming false if it wasn't provided. This would be a feature for us to detect the presence of the claim and act differently if it isn't there. Do any other providers do this? Almost all that I've worked with do support this claim.
Hi , Enterprise providers like ADFS , Okta don't support this as part of the user schema. There is the concept of whether a use is active/enabled which is not the same as email verified always.

If a user is not active, a token should not be minted in the first place. I am trying to understand what additional security does email_verified provided in the context of entire identity providers where there is no self self service use creation. Thanks, Sree
Okta supports , but it looks like ADFS doesn't: We don't know when the provider is self-service or not. Not assuming makes the client logic uniform and less error prone instead of trying to reason about the intent of the provider. There's some discussion when we enabled this validation, including some UAA notes. , specifically
More than 80% of the enterprise customers of Cloud Foundry are using either AD/ADFS . This becomes a breaking change. UAA can add a email_verified claim. However its going to be of little value if the underlying AD doesn't propagate that. My two cents is this check doesn't make sense in an enterprise set up
has agreed to take this (can't assign her because she's not part of the org) /sig auth /kind feature /milestone v1.11 /priority important-longterm /status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners; move out of the milestone after 1 attempt. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details