10 Feb
2025
10 Feb
'25
10:39 a.m.
I don't think FAST is tied to any particular SASL
mechanisms? That's why
we
duplicate mechanism discovery as part of FAST, which is the main thing I'm
talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I
think would work for FAST and also for other things such as app passwords:
When requesting a FAST token, return the token and also a SASL authcid value
to go along with it. Then when doing authentication in the future, this
authcid will select which credential to check against (the FAST token)
instead of using a custom mechanism (the <fast/> tag). This solves
one of the two warts in a way that works with SASL instead of
reinventing it.
Now, as for the duplicate mechanisms thing, I don't personally see why this
is needed at all at this point. A token is a password and thus should work
with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc).
However, in case we want to still allow servers to not implement FAST for
every relevant SASL mechanism they support, I would suggest this change.
Instead of:
The problem is that for some mechanisms and authentication backends,
the server needs to know what kind of credentials are being used
up-front. In an ideal world, I think we would have SASL able to encode
this information.
Specifically, there are two things the server needs to know:
1) The type of credential being used (password, FAST token, bearer token, etc.)
2) In some cases, some identifier of the credential being used (when
the same user has multiple credentials of the same type, common with
tokens)