You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at square/go-jose#286 and #10 (merged), I see a bit of an issue: the existing behavior in v3.0.0 is that each audience in an Expected must match an audience in a Claim for Validate to pass. The behavior at the head of the v3 branch is that one audience in an Expected must match an audience in a Claim for Validate to pass.
This is correct behavior per the spec, but is a potentially breaking change in an authorization code path, with no accompanying change in types or names to make sure people pay attention. I'm concerned that users may be depending on the old behavior (each matches) and silently break when upgrading.
Here's my proposed fix: restore the old behavior for Expected.Audience, and deprecate that field. Add a new field Expected.SingleAudience string, and give the new behavior to that field.
The text was updated successfully, but these errors were encountered:
jsha
changed the title
Auth behavior change for multiple audiences
Authorization behavior change for multiple audiences
Jan 13, 2023
Per #23, PR #10 (unreleased) made the authorization properties of
Claims.Validate more relaxed. Given that people may have been relying on
those authorization properties, we shouldn't make that change without a
change in API surface or a major version bump.
Looking at square/go-jose#286 and #10 (merged), I see a bit of an issue: the existing behavior in v3.0.0 is that each audience in an Expected must match an audience in a Claim for Validate to pass. The behavior at the head of the v3 branch is that one audience in an Expected must match an audience in a Claim for Validate to pass.
This is correct behavior per the spec, but is a potentially breaking change in an authorization code path, with no accompanying change in types or names to make sure people pay attention. I'm concerned that users may be depending on the old behavior (each matches) and silently break when upgrading.
Here's my proposed fix: restore the old behavior for
Expected.Audience
, and deprecate that field. Add a new fieldExpected.SingleAudience string
, and give the new behavior to that field.The text was updated successfully, but these errors were encountered: