The OAuth is complicated. Is it worth to maintain both OAuth and OAuth2 in a single codebase?
no plus ones
View 3 previous comments
- The two parts may not depend on each other, but they probably depend on the shared functionality, and shared functionality usually affects the way the code is written.
The RFC 6749 (OAuth 2) obsoletes RFC 5849 (OAuth 1), so the presence of two implementations (and the name draft25) makes me think about other things that are left in code for backwards compatibility.
What you're saying about is probably "maintenance complexity", not "code complexity". It is not even "usage complexity", because from the point of OAuth users they still need to choose either OAuth 1 or OAuth 2. They can't use both at the same time, and even if they do - it's quite unlikely that a single endpoint will be used for that.Feb 17, 2013
- Feb 17, 2013
- OAuth2 doesn't obsolete OAuth1. They share the same name but are quite different in many aspects. Some people even still consider OAuth1 to be superior.
Besides, if you look at oauthlib codebase, it doesn't share any parts between 1 and 2 that would cause troubles. It's usualy just helper methods (for generating tokens etc).
Regarding implementation of OAuth2's RFC, I believe is working on it and it should be ready for testing soon.
In short: If you don't need to use OAuth1, just don't use it, but IMO it's still worth to maintain it.Feb 17, 2013
- http://tools.ietf.org/html/rfc6749you may say that OAuth1 doesn't obsolete OAuth2, but RFC 6749 says otherwise -
I agree that actual code is not tightly coupled, but this fact is only evident after actually asking or reading the code, which users of the library rarely do. If the lib seems too complicated - they bounce.
So, while your facts provide additional info, they doesn't cancel the argument that from the user's perspective it is better to see different in many aspects and independent on each other libraries in different projects.Feb 17, 2013
- I've added an issue https://github.com/idan/oauthlib/issues/116 even though I don't expect it to be fixed. Just interesting to track the opinions on the matter.Feb 17, 2013
- Ib LundgrenOwnerI've added my thoughts to the github issue.
Regarding OAuth 2 obsoleting OAuth 1 that is not quite true, yet. There are still use cases that are not covered by OAuth 2, the ones being users that are unable to rely on SSL (partially addressed in the abandoned MAC token spec) and Holder of Key assurance (supposedly addressed in the upcoming Holder of Key).Feb 18, 2013
Add a comment...