4 ms·
I get the feeling that this seems to be a common issue with any authentication or authorization "standard" nowadays. When I had to implement SASL OUATHBEARER su
by jcranmer 5y ago
I get the feeling that this seems to be a common issue with any authentication or authorization "standard" nowadays. When I had to implement SASL OUATHBEARER support, and I started poking around how to actually implement OAuth2 from the standard itself, it was similarly full of "here's several ways that you might do something, and whether or not they're supported by the provider is implementation-defined, and what you have to provide with the requests is implementation-defined, and where you go to find the stuff is implementation-defined."
And frustratingly for me--trying to implement this in the course of a SASL method as a client--there's not even anything hooked up in SASL that might have hinted at the client what to do. Which is insane because the entire point of SASL is to bridge the gap of "how to request authorization given username, hostname, protocol." It makes me want to retreat back into Kerberos as a better way of supporting SSO than anything invented in the decades after it.
- icedchai 5y agoLast I checked, and having worked on a few oauth clients, OAuth2 is more of a set of rough guidelines.
- sarnowski 5y agoCorrect, it’s officially a framework and not a protocol. It’s a framework to build a specific protocol which then is using the same patterns as other OAuth2 based protocols but not necessarily compatible. For example URL endpoints are not defined in a strict sense and the provider can also add arbitrary parameters to calls as long as the basic OAuth2 parameter are present as well. OpenID Connect 1.0 builds on that to make the framework more strict. RFC6749 The OAuth 2.0 Authorization _Framework_