4 ms·

I'm not sure the author understands the benefit of OAuth. here's an analogy: First, let's assume that the end user uses the same username/password combination

I'm not sure the author understands the benefit of OAuth. here's an analogy: First, let's assume that the end user uses the same username/password combination for every website, which is quite common. Also, assume that twitter and your server accept the username/password combination as a basic auth encoded string. What you have, in OAuth terms, is a universally acceptable auth token, without the shared secret (similar to an unsalted password hash). Anyone in possession of this token can access any resource on any website as the end user (assuming they have a single username/password everywhere). So OAuth allows you to take this universal token (or at least the information contained in this token: username/pass), and generate a new access token which can only access a limited resource for a given service, sometimes for a limited period of time. Also, it has a shared secret, so it's harder to abuse. For the end user, it's actually much safer to keep the access token & secret locally vs. making them login to your central service with a username/password. If the username/password gets out, they no longer control their identity online. If the access token/secret gets out, they no longer control the resource.

ownedthx 17y ago
A good summary of OAuth, but as the author, I assure you I do understand this key benefit of OAuth. Admittedly I didn't make a point of it, but there are alot of sites that do a good job of explaining this (as well as your comment). The issue of the article isn't that. It's when one is actually building a desktop application from scratch. You end up building a web site with a user login... just so you can store the application secret securely! Note that when I say application secret, I'm not referring to the user's access token & secret that you point out. I agree that storing that info locally on the desktop is fine. Thanks for replying.
- weavejester 17y ago
  I'm not sure I understand why a desktop application needs to authenticate itself with your server via a username and password in order to use OAuth. Could you explain further?
  - ownedthx 17y ago
    If you can agree that there is no way to safeguard the application secret key other than keeping it on a server (no matter how u try to bury it in the desktop application, it could be hacked no?), then you have to let your desktop application 'instances' use some sort of API to get their messages signed. But, you don't want to let anyone just come in and hit this API! That could be expensive, in terms of CPU, bandwidth, and hosting costs. So you want to make sure the desktop application is indeed authorized to do so. So then you need some sort of authentication scheme between your desktop applications and your server... username/passwords being a common such way.
    - weavejester 17y ago
      I'm afraid I still don't quite understand how a username and password is required. If it is free to sign up for a username and password, then people could just sign up with your service and then hit your API directly. All you've added is an inconvenient barrier for your users that wouldn't stop an attacker. After all, if the attacker can be bothered figuring out how your application talks to your server, he or she can probably be bothered signing up for a username and password. On the other hand, if your application costs money, then why not require a valid license key to access your server. True, you'll get the problem of people pirating software and reusing the license key, but it shouldn't be too hard to monitor your server logs and ban any license key that is submitted by a large number of unique IP addresses in a short period.

ownedthx 17y ago

A good summary of OAuth, but as the author, I assure you I do understand this key benefit of OAuth. Admittedly I didn't make a point of it, but there are alot of sites that do a good job of explaining this (as well as your comment). The issue of the article isn't that. It's when one is actually building a desktop application from scratch. You end up building a web site with a user login... just so you can store the application secret securely! Note that when I say application secret, I'm not referring to the user's access token & secret that you point out. I agree that storing that info locally on the desktop is fine. Thanks for replying.

weavejester 17y ago
I'm not sure I understand why a desktop application needs to authenticate itself with your server via a username and password in order to use OAuth. Could you explain further?
- ownedthx 17y ago
  If you can agree that there is no way to safeguard the application secret key other than keeping it on a server (no matter how u try to bury it in the desktop application, it could be hacked no?), then you have to let your desktop application 'instances' use some sort of API to get their messages signed. But, you don't want to let anyone just come in and hit this API! That could be expensive, in terms of CPU, bandwidth, and hosting costs. So you want to make sure the desktop application is indeed authorized to do so. So then you need some sort of authentication scheme between your desktop applications and your server... username/passwords being a common such way.
  - weavejester 17y ago
    I'm afraid I still don't quite understand how a username and password is required. If it is free to sign up for a username and password, then people could just sign up with your service and then hit your API directly. All you've added is an inconvenient barrier for your users that wouldn't stop an attacker. After all, if the attacker can be bothered figuring out how your application talks to your server, he or she can probably be bothered signing up for a username and password. On the other hand, if your application costs money, then why not require a valid license key to access your server. True, you'll get the problem of people pirating software and reusing the license key, but it shouldn't be too hard to monitor your server logs and ban any license key that is submitted by a large number of unique IP addresses in a short period.