Actually, my question is in the title of the post itself. So, really, in RFC OAuth called framework, but in a lot of articles, it's called protocol. So what is the proper name and why?
As I know protocol is a set of rules - and it seems to be relevant in that case. Under the framework, I usually understand a set of some components (e.g. programming language classes) that would be helpful in some process (e.g. development).
Can somebody clarify it to me? Thanks a lot!
From IETF site:
Memos in the Requests for Comments (RFC) document series contain technical and organizational notes about the Internet. They cover many aspects of computer networking, including protocols, procedures, programs, and concepts, as well as meeting notes, opinions, and sometimes humor.
For instance, RFC 791, published back in 1981, describes the Internet Protocol. It describes how it works, and provides pseudo-code, describing how the protocol should be implemented. It does not provide any code in the "framework" or "toolset" sense, and does not tell how an actual Internet router should be designed.
The same goes with RFC 6749 (OAuth 2) - the RFC describes the protocol and discusses how it should be implemented.
In OAuth's case RFC talks both about a protocol and a framework more or less as synonyms. The same goes on e.g. in oauth.net site, even on the front page. The name of the RFC itself is "The OAuth 2.0 Authorization Framework". So, semantically I think both "protocol" and "framework" are correct in this case.
But in practice you can just think about RFC as "protocol definition", and actual protocol implementations (that you can utilize) on different languages as "frameworks" in the meaning you described in the question.
To get a good explanation about it, I think it worths to watch the follow video about OAuth 2.0 by Eran Hammer.
https://vimeo.com/52882780
Here, you can understand why the title of RFC 6749 was changed to Framework instead of Protocol. In few words, OAuth 2.0 isn't interoperable as detailed at section 1.8 from RFC 6749:
However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.
I hope this better helps you understand.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With