🔒 SASL: Clarify usage of username vs authcid vs authzid #187
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.
Different SASL mechanisms use the term "username" differently. In general the pattern seems to be the following:
username
at all, and instead use the terms Authentication Identity (authcid
) and Authorization Identity (authzid
).authcid
andauthzid
.username
may be semantically equivalent toauthcid
,authzid
, or both.authcid
) and an Authorization Identityauthzid
,username
commonly refers to theauthcid
.username
commonly refers to theauthzid
Every mechanism's keyword arguments, positional arguments, and documentation has been updated to match this terminology. Aliases have been added from
username
toauthcid
orauthzid
—or in the other direction, fromauthcid
orauthzd
tousername
Instead of raising an exception, conflicting arguments are treated like silently ignored. This allows more specific argument (like
authcid
or a keyword argument) to be used like an override to more generic terms (likeusername
or a positional argument). This could simplify using a single hash of keyword arguments with multiple SASL mechanisms, which could facilitate dynamically negotiating the mechanism, or automatically retrying multiple acceptable mechanisms.OAuthBearerAuthenticator
was updated to allow two arguments, in order to match the commonauth(username, secret)
parameter style. In my opinion, this makes the API a little bit more confusing. But the mechanism only requires one argument, so it's natural to allow a single argument version. And this two argument version matches with how many clients and applications seem to assume the SASL mechanisms always work.