Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorization behavior change for multiple audiences #23

Open
jsha opened this issue Jan 13, 2023 · 1 comment
Open

Authorization behavior change for multiple audiences #23

jsha opened this issue Jan 13, 2023 · 1 comment

Comments

@jsha
Copy link
Collaborator

jsha commented Jan 13, 2023

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.

@jsha jsha changed the title Auth behavior change for multiple audiences Authorization behavior change for multiple audiences Jan 13, 2023
jsha added a commit that referenced this issue Nov 9, 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.
@jsha
Copy link
Collaborator Author

jsha commented Nov 9, 2023

Bumping this issue to say we reverted the behavior change, but plan to roll it forward in a v4 branch (with an updated field name).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant