Make invite email-binding enforcement opt-in - #56
Merged
Conversation
Invite.EmailClaim defaulted to 'email', which silently turned gateway email binding on for any deployment whose invite tokens already carry an 'email' claim - a behavior change imposed on framework consumers by upgrade alone. Default EmailClaim to empty so gateway enforcement is opt-in, while the authenticated account's verified email is still forwarded to the exchange endpoint unconditionally. Deployments that want the gateway to reject a mismatched account set EmailClaim explicitly; everyone else keeps the prior behavior and can enforce the binding in their own exchange endpoint. Specs opt in to enforcement via an overridable email claim, with an added spec proving a mismatch is forwarded (not rejected) when EmailClaim is unset. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Clarify that Invite.EmailClaim is empty by default (gateway enforcement off), that setting it enables the verified-email match, and that the verified email is forwarded to the exchange endpoint regardless. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to the invite trust-boundary hardening (#55). That change added
Invite.EmailClaimwith a default ofemail, which meant gateway email-binding enforcement turned on automatically for any deployment whose invite tokens already carry anemailclaim — a policy change imposed on framework consumers by upgrade alone, and one that could reject invites that were previously accepted.This makes the gateway enforcement opt-in while keeping the useful, low-risk half unconditional: the authenticating account's verified email is still always forwarded to the exchange endpoint, so an app can enforce the invited-email/authenticated-email binding itself. Deployments that want AuthProxy to reject a mismatched account at the gateway now enable it explicitly by setting
Invite.EmailClaim.Phase-2 token re-validation (the signature/issuer/audience/lifetime re-check from #55) is unaffected and stays on.
Changed
Invite.EmailClaimnow defaults to empty, so gateway email-binding enforcement is off by default. Set it (for example toemail) to require the authenticated account's verified email to match the invited email at the Phase-2 exchange. The verified email is forwarded to the exchange endpoint regardless of this setting, so the backend can still enforce the binding itself.