-
Notifications
You must be signed in to change notification settings - Fork 29
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
🔒 SASL: Clarify usage of username vs authcid vs authzid #187
Merged
nevans
merged 5 commits into
ruby:master
from
nevans:sasl/username-vs-authcid-vs-authzid
Oct 20, 2023
Merged
🔒 SASL: Clarify usage of username vs authcid vs authzid #187
nevans
merged 5 commits into
ruby:master
from
nevans:sasl/username-vs-authcid-vs-authzid
Oct 20, 2023
Conversation
This file contains 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
nevans
force-pushed
the
sasl/username-vs-authcid-vs-authzid
branch
from
October 4, 2023 16:54
71ea9fd
to
56459e1
Compare
37 tasks
nevans
force-pushed
the
sasl/username-vs-authcid-vs-authzid
branch
from
October 8, 2023 03:27
56459e1
to
2576cad
Compare
nevans
force-pushed
the
sasl/username-vs-authcid-vs-authzid
branch
from
October 10, 2023 03:19
2576cad
to
edb6040
Compare
This was referenced Oct 15, 2023
Harmonized the formatting and language of SASL mechanism parameters. Made a few corrections (e.g. where `PLAIN` should have been `XOAUTH2`). Added some RFC reference links. Etc.
Different SASL mechanisms use the term "username" differently. In general the pattern seems to be the following: * Some mechanisms avoid using the term `username` at all, and instead use the terms Authentication Identity (`authcid`) and Authorization Identity (`authzid`). * Older or non-standard mechanisms may not distinguish clearly between `authcid` and `authzid`. `username` may be semantically equivalent to `authcid`, `authzid`, or both. * When the mechanism supports an explicit `authcid` and an `authzid`, `username` commonly refers to the `authcid`. * When the authentication identity is derived from other credentials, `username` commonly refers to the `authzid`. Every mechanism's keyword arguments, positional arguments, and documentation is updated to match this terminology. Aliases have been added from `username` to `authcid` or `authzid`—or in the other direction, from `authcid` or `authzd` to `username`.
`OAuthBearerAuthenticator` was updated to allow two arguments, in order to match the common `auth(username, secret)` parameter style. In my opinion, this makes the API a little bit 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.
Instead of raising an exception, conflicting arguments are silently ignored. This allows more specific argument (like `authcid` or a keyword argument) to be used like an override to more generic terms (like `username` or a positional argument). It should also simplify using a single set of keyword credentials with multiple SASL mechanisms, which could facilitate dynamically negotiating the mechanism, or automatically retrying multiple acceptable mechanisms.
These are added to give _all_ mechanisms the same basic argument semantics. If it were just for `Net::IMAP`, I'd say it's not worth it. However, to make this `SASL` implementation fully compatible with others—such as `net-smtp`.
nevans
force-pushed
the
sasl/username-vs-authcid-vs-authzid
branch
from
October 19, 2023 23:44
70c0311
to
34e4662
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.