[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 with SMTP id m3mr5073506qcm.137.1304221847341; Sat, 30 Apr 2011 20:50:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 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?

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