3 ms·

I agree asking for passwords is bad, but he'd probably have gotten cooperation from third parties much more quickly if he were following OAuth, OAuth2 or some o

I agree asking for passwords is bad, but he'd probably have gotten cooperation from third parties much more quickly if he were following OAuth, OAuth2 or some other widely used standard. Forcing others to write bespoke code to handle a weird non-standard auth, however simple, is a major impediment to people using the Pinboard API. Also, promising to break working integrations with the "ban hammer" seems like a poor reward to give users for alerting you to a problem. If a user values the integration more than the security of their bookmark list (as I'm guessing many people do, given the number of people using Pinboard via IFTTT), they won't be reporting that to you.

pkulak 12y ago
Especially considering that OAuth2 pretty much _is_ just a single token.
deleted 12y ago
[deleted]
kijin 12y ago
If you talk to any HTTP API these days, you probably use a proper API client library (of which Pinboard has plenty) rather than manually crafting HTTP requests with curl. If so, it doesn't matter whether the API supports $popularAuthMethod or not. You just pass the token to the client library and let the client library handle it from there.
archagon 12y ago
Yeah, but the Pinboard API is extremely simple to use, and the token is shown in BIG BOLD LETTERS on the settings page. Frankly, it's easier to implement than username/password, especially since the audience is probably mostly comprised of tech-savvy power users. OAuth would add a framework's worth of complexity to this simple and elegant system — qualities that the developer of Pinboard clearly holds dear.
- 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]
idlewords 12y ago
My users don't value the integration over security. I'm doing this due to ongoing user complaints about IFTTT (who have just fixed their implementation, bless them) prompting for a password. I'm available at an attractive daily consulting rate for anyone who needs help adding an auth token to their query string with each API call.
flashman 12y ago
Let's review the many reasons to use something simpler than OAuth: http://insanecoding.blogspot.com/2013/03/oauth-great-way-to-cripple-your-api.html http://insanecoding.blogspot.com/2013/03/oauth-great-way-to-...

pkulak 12y ago

Especially considering that OAuth2 pretty much _is_ just a single token.

deleted 12y ago

[deleted]

kijin 12y ago

If you talk to any HTTP API these days, you probably use a proper API client library (of which Pinboard has plenty) rather than manually crafting HTTP requests with curl. If so, it doesn't matter whether the API supports $popularAuthMethod or not. You just pass the token to the client library and let the client library handle it from there.

archagon 12y ago

Yeah, but the Pinboard API is extremely simple to use, and the token is shown in BIG BOLD LETTERS on the settings page. Frankly, it's easier to implement than username/password, especially since the audience is probably mostly comprised of tech-savvy power users. OAuth would add a framework's worth of complexity to this simple and elegant system — qualities that the developer of Pinboard clearly holds dear.

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]

idlewords 12y ago

My users don't value the integration over security. I'm doing this due to ongoing user complaints about IFTTT (who have just fixed their implementation, bless them) prompting for a password. I'm available at an attractive daily consulting rate for anyone who needs help adding an auth token to their query string with each API call.

flashman 12y ago

Let's review the many reasons to use something simpler than OAuth: http://insanecoding.blogspot.com/2013/03/oauth-great-way-to-cripple-your-api.html http://insanecoding.blogspot.com/2013/03/oauth-great-way-to-...