Re: [OAUTH-WG] Redirects

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 07 May 2010 06:11 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 13F3B3A6A99 for <oauth@core3.amsl.com>; Thu, 6 May 2010 23:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.3
X-Spam-Level: *
X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, 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 IoGjYkgzgkDN for <oauth@core3.amsl.com>; Thu, 6 May 2010 23:11:08 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 9AD7B3A6819 for <oauth@ietf.org>; Thu, 6 May 2010 23:09:54 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.52,346,1270389600"; d="p7s'?scan'208,217"; a="2836063"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 07 May 2010 16:09:41 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1690423"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccni.tcif.telstra.com.au with ESMTP; 07 May 2010 16:09:41 +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 16:09:41 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: David Recordon <recordond@gmail.com>
Date: Fri, 07 May 2010 16:09:40 +1000
Thread-Topic: [OAUTH-WG] Redirects
Thread-Index: AcrtpyvQjD80fZDqQWGuGphhPdGG+QABI7EQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B26C0@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <q2hfd6741651005062105y46152452x370fac0dd12d55c6@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> <v2nfd6741651005062235g211564dfr6aaf6a72bf4dfaa@mail.gmail.com>
In-Reply-To: <v2nfd6741651005062235g211564dfr6aaf6a72bf4dfaa@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0068_01CAEDFF.B28E8B10"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Redirects
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 06:11:10 -0000

David said:

> Why wouldn't the client send the token with the new request? If I'm trying to access https://api.example.com/pr?access_token=loin21op and I get a 301 response, I'll need to follow that if I want any chance of accessing the protected resource.

 

 

If https://api.example.com/pr?access_token=loin21op responses with “Location: http://evil.com/log” should the client get http://evil.com/log or http://evil.com/log?access_token=loin21op? Surely the later is potentially insecure. I don’t think we can assume (mandate) that services only redirect to “good” sites. We certainly can’t assume (mandate) that links in the content on the response are to “good” sites.

 

The answer is a bit easier if the token is passed as a query param (like with Facebook) -- as the client could rely on the service to include or omit the token param in the redirect/link URI as appropriate. It is less obvious with an Authorization header, or POST is used.

 

--

James Manger