[OAUTH-WG] OAuth 1.0 2-legged scenario
Andrew Arnott <andrewarnott@gmail.com> Sun, 01 May 2011 03:50 UTC
Return-Path: <andrewarnott@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73CE0709 for <oauth@ietfa.amsl.com>; Sat, 30 Apr 2011 20:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYBlNDJfW-wh for <oauth@ietfa.amsl.com>; Sat, 30 Apr 2011 20:50:48 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF52E0691 for <oauth@ietf.org>; Sat, 30 Apr 2011 20:50:48 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2960356qwc.31 for <oauth@ietf.org>; Sat, 30 Apr 2011 20:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=OIGyl2V37Xqf0jWVYq2czOdca7x8zich0/ZGnEMTbxg=; b=kwKEdWgXC7l50zNgl/M2WdwJDQ2W9j3bi7k9VCABD4xWAuXUKPhLNvFPP042JCmNwW eWiYs8Uc1U50AQwJFjvbYUaaODfqn518TBiYCJvN9tdkrMwfMDX3FCaRCy3DrgETHP0G LBUc9rpkBq1TT6KhQMloDldrIPTUxQbUDvuOU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=DjWGJ/jcwXxq40aA39SjJnEsjpB1rAZrAEU6sWTK2cm9pghLxrXCuhe5AknU2Un42f waqdOjDQFt+bwK+TY7fijEBEHkHuYGGetycTZEspsT+ewMNP/XqUXTybVbt/JTRu1sSn qEW7SxzOKQl9JTyB/Tps/Qn526KY/KUWGtVEM=
Received: by 10.229.9.195 with SMTP id m3mr5073506qcm.137.1304221847341; Sat, 30 Apr 2011 20:50:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.82.83 with HTTP; Sat, 30 Apr 2011 20:50:27 -0700 (PDT)
From: Andrew Arnott <andrewarnott@gmail.com>
Date: Sat, 30 Apr 2011 20:50:27 -0700
Message-ID: <BANLkTini_fuL4EjLOm_W=J=C4N4i1q+kYg@mail.gmail.com>
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0016360e3f5ceb4a8d04a22ecfb8"
Subject: [OAUTH-WG] OAuth 1.0 2-legged scenario
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 May 2011 03:50:49 -0000
Does this doc<http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html>accurately describe what the community generally refers to as "two-legged OAuth"? If so, I have a couple questions... What about this is "*two* legged"? I count zero legs. The consumer already has a key and secret, and uses them to access resources. Not a single one of the 3 legs in standard OAuth's "unauthorized request token, authorize, exchange for access token" flow are present in the above linked spec by my reading of it. I expected two-legged OAuth to be more like this: 1. The client presumably already has a consumer key, but perhaps no secret since these clients can rarely keep secrets. I'm imagining clients that are desktop sidebar gadgets, perhaps. 2. Upon first run, this app performs these two legs: 1. Obtains a request token using the standard OAuth 1.0 flow. This would traditionally be an unauthorized request token. But in 2-legged OAuth this request token is implicitly auto-authorized, for access to a new, empty account on the service provider. 2. Exchanges the request token for an access token, again using the standard OAuth 1.0 flow for that step. 3. At this point, the client has a consumer key, perhaps a consumer secret, and an access token and token secret. The token represents an empty account, but may be filled and later queried by that client. The fact that the client has no consumer secret is of little consequence because the access token secret is unique for this particularly installation of the client and therefore the data is protected. So... which one is right? And does the "wrong" one have any validity? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
- [OAUTH-WG] OAuth 1.0 2-legged scenario Andrew Arnott
- Re: [OAUTH-WG] OAuth 1.0 2-legged scenario Eran Hammer-Lahav
- Re: [OAUTH-WG] OAuth 1.0 2-legged scenario Brian Eaton