Re: [OAUTH-WG] Indicating sites where a token is valid

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 07 May 2010 01:36 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960493A6857 for <oauth@core3.amsl.com>; Thu, 6 May 2010 18:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.24
X-Spam-Level: *
X-Spam-Status: No, score=1.24 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPCxUlkKms+u for <oauth@core3.amsl.com>; Thu, 6 May 2010 18:36:32 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id E11643A6890 for <oauth@ietf.org>; Thu, 6 May 2010 18:36:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,344,1270389600"; d="scan'208";a="2175841"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 07 May 2010 11:36:18 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1663432"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 07 May 2010 11:36:18 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 7 May 2010 11:36:18 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Marius Scurtescu <mscurtescu@google.com>
Date: Fri, 07 May 2010 11:36:16 +1000
Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid
Thread-Index: Acrted66i8DdRZnsQ1+d4Zfwy7YRwAABetmg
Message-ID: <255B9BB34FB7D647A506DC292726F6E112630740C0@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTinnJHoLQoQvIQ_yEeJ2nnRd0--r0m9orGI1oZbJ@mail.gmail.com>
In-Reply-To: <AANLkTinnJHoLQoQvIQ_yEeJ2nnRd0--r0m9orGI1oZbJ@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 07 May 2010 01:36:33 -0000

Marius

> Isn't this taken care of by the scope?

I don't think so. It looks similar to Google scopes (http://code.google.com/apis/gdata/faq.html#AuthScopes), but nothing like Facebook scopes (http://developers.facebook.com/docs/authentication/permissions).


> I assume the requested scope is associated with the issued access token.

I don't think we should require client apps to know all the sites a service uses for its resources (even those in a given scope) at the start of the flow. It kills interop for clients without much service-specific knowledge. It also constrains how services arrange (and re-arrange) their resources.

What should a client do when, on accessing a protected resource, it is redirected to another site?
Does it send the token to the new site?
Sometime sending the token will be dangerous — the other site shouldn't see these confidential tokens (eg https://api.example.com -307-> http://cdn.net/236423).
In other situations the token should be sent as the same service control both sites equally (eg https://api.example.com -307-> https://account.example.com).


As a concrete example, access the Facebook API such as https://graph.facebook.com/btaylor?metadata=1 and the response lists dozens of other URIs. Most of the URI are on the same site (https://graph.facebook.com) so presumably a client app can send the same token. Another URI is at a related site (http://www.facebook.com), but doesn't use TLS. Even if an app could tell this domain was "related" it probably shouldn't send the same token. If one of the listed connections was to an external site (eg "blog":"https://blog.example.org") I would assume the same token should NOT be sent.

The app needs to be given the list of sites appropriate for its token to make these decisions safely.


> It is up to the sites accepting the access tokens
> (the protected resources) to verify and enforce the scope.

A site cannot prevent a token being sent from a client app to the wrong site, because the right site never sees the traffic.

-- 
James Manger


On Thu, May 6, 2010 at 4:57 PM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
> I suggest another field in the JSON token response:
>
>   "sites": ["https://api.example.com", "http://photo.example.com:8080"]