3 ms·
Author here. I wrote this draft a few years ago after getting frustrated with OAuth 2.0. And, whilst I am grateful for llambda for posting it to HN, it was neve
by tav 14y ago
Author here. I wrote this draft a few years ago after getting frustrated with OAuth 2.0. And, whilst I am grateful for llambda for posting it to HN, it was never meant to be published in this unfinished state. So please bear this in mind as you come across incomplete sections.
I never bothered to finish it back in 2010 since everyone seemed quite content with OAuth 2.0 at that time. However, now that it has been posted, I would love to know if anyone would like to see a completed version.
[Edit: Also, any criticisms of what's already there and thoughts on anything else you feel should be included would be really appreciated. Thanks!]
- yawnt 14y agoi'd love to ;3
- jokull 14y agoStandards vacuum. Maybe reach out to the GitHub API dev’s. Having a powerful but open minded adopter would help a lot. Maybe contact the developer behind flask-oauthprovider [1] (oauth 1). I see you have some flask-sqlalchemy type snippets in there. [1]: https://github.com/ib-lundgren/flask-oauthprovider https://github.com/ib-lundgren/flask-oauthprovider
- icheishvili 14y agoAs the author of several OAuth 1.0 libraries (https://github.com/icheishvili/pyoauth https://github.com/icheishvili/pyoauth, https://github.com/icheishvili/phoauth https://github.com/icheishvili/phoauth), I would like to see a completed spec. The only real problem with 1.0 is the difficulty of implementing it correctly and later debugging it when things go wrong (aka, the infamous generic "Invalid Signature" errors). In my mind, it would go a long way if generating a signature was based on a random nonce (say 16 bytes) + client id + client secret + access token.