3 ms·

I once had to write an OAuth client for each of the major invoice/accounting cloud services. It was a huge hassle, with very little standardization. Everyone ha

by briholt 12y ago

I once had to write an OAuth client for each of the major invoice/accounting cloud services. It was a huge hassle, with very little standardization. Everyone had to add their little quirk to the system (like client-specific endpoints, or some quirky encoding, or only accepting HTTP headers and not POST fields), depleting all the value of using the OAuth "standard," leaving only a bulky OAuth library. Simple GET/POST fields are much easier and can easily be transparently maintained in a few lines of code.

cakoose 12y ago
OAuth is basically two decoupled things: the request authentication format and the app authorization flow. Request authentication in OAuth 2 is typically done by adding the HTTP header "Authorization: Bearer <access-token>" to every request. Pinboard does something similar but different. Sure, it would be nice if everyone used the same format, but it's so easy to stick a token in an HTTP request that I don't care if Pinboard uses its own format. The app authorization flow is how a 3rd-party app gets an access token. (It's when the 3rd-party site redirects the user's browser to a Pinboard app approval page, where the they can click "allow", which tells Pinboard to give an access token to the 3rd-party site.) Right now Pinboard just has you copy/paste a fixed token, which is fine, too. I think having an app authorization flow would make for a slightly better user experience. The hardest part is designing an app authorization flow that is secure. Most of us are just not capable of doing that, so it's much safer to just use OAuth 2. As a side benefit, you can use existing OAuth 2 libraries, which will save you time on the server and on each client. Yeah, the OAuth 2 spec is not written well. I had to jump back and forth a bunch trying to figure out exactly what the spec wanted me to do. But overall I think the benefits of using OAuth 2 for your app authorization flow outweight the annoyances.
deleted 12y ago
[deleted]

by briholt 12y ago

cakoose 12y ago

OAuth is basically two decoupled things: the request authentication format and the app authorization flow. Request authentication in OAuth 2 is typically done by adding the HTTP header "Authorization: Bearer <access-token>" to every request. Pinboard does something similar but different. Sure, it would be nice if everyone used the same format, but it's so easy to stick a token in an HTTP request that I don't care if Pinboard uses its own format. The app authorization flow is how a 3rd-party app gets an access token. (It's when the 3rd-party site redirects the user's browser to a Pinboard app approval page, where the they can click "allow", which tells Pinboard to give an access token to the 3rd-party site.) Right now Pinboard just has you copy/paste a fixed token, which is fine, too. I think having an app authorization flow would make for a slightly better user experience. The hardest part is designing an app authorization flow that is secure. Most of us are just not capable of doing that, so it's much safer to just use OAuth 2. As a side benefit, you can use existing OAuth 2 libraries, which will save you time on the server and on each client. Yeah, the OAuth 2 spec is not written well. I had to jump back and forth a bunch trying to figure out exactly what the spec wanted me to do. But overall I think the benefits of using OAuth 2 for your app authorization flow outweight the annoyances.

deleted 12y ago

[deleted]