I assume you really want to know.
On Wednesday 12 February 2020 01:14:38 CET, Steffen Nurpmeso wrote:
Now. Why can't you just use plain text authentication with this
access token, why must it be XOAUTH2/OAUTHBEARER?
The special trait is that oauth tokens resist being copied.
If you gain access to someone's token and copy it, then your copy is
invalidated soon. You can use your copy for a while, but then the rightful
user uses it and the client and server cooperate to invalidate your copy.
Why do you need an OAuth framework if you do support these two?
Just offer a diversified set of passwords, one master, one for
each service. Where is the difference?
Why don't you either introduce service additions to refresh the
access token, or extend the XOAUTH2/OAUTHBEARER "JSON" (why JSON?
why not \0 terminated sub\0strings\0\0, like for others? Why
JSON?) query/response with that possibility?
(password=PASS\0refresh=yes\0\0?)
The SASL mechanisms that were specified by Mark Crispin used null
separators and double-null terminators, the ones that were specified by
people who tried to make them like Mark's used nulls, but OAUTH isn't in
that set. It's one of the SASL mechanisms that import an authentican
mechanism from outside SASL, and those tend to be like the thing they
import.
Good thing too IMO. I hate it when someone imports a spec and then changes
details that were NIH.
Arnt
