Re: [OAUTH-WG] Why give the redirect URI when trading an access code for an access token?

Eran Hammer-Lahav <eran@hueniverse.com> Fri, 10 September 2010 15:06 UTC

Return-Path: <eran@hueniverse.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 E524F3A67EF for <oauth@core3.amsl.com>; Fri, 10 Sep 2010 08:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level:
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599]
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 cNNdAkTvzv8O for <oauth@core3.amsl.com>; Fri, 10 Sep 2010 08:06:01 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D63FE3A689F for <oauth@ietf.org>; Fri, 10 Sep 2010 08:06:01 -0700 (PDT)
Received: (qmail 15894 invoked from network); 10 Sep 2010 15:06:28 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Sep 2010 15:06:28 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 10 Sep 2010 08:06:28 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "Freeman, Tim" <tim.freeman@hp.com>, "oauth@ietf.org" <oauth@ietf.org>
Date: Fri, 10 Sep 2010 08:06:23 -0700
Thread-Topic: [OAUTH-WG] Why give the redirect URI when trading an access code for an access token?
Thread-Index: ActPy7z55fqeLYGoQ5ugjINJWPMP0wBLShvQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F3F0703@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <59DD1BA8FD3C0F4C90771C18F2B5B53A6532547F10@GVW0432EXB.americas.hpqcorp.net>
In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A6532547F10@GVW0432EXB.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Why give the redirect URI when trading an access code for an access token?
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, 10 Sep 2010 15:06:03 -0000

1. Evil user starts the OAuth flow on the client using the web-server flow.
2. Client redirects the evil user to the authorization server, including state information about the evil user account on the client.
3. Evil user takes the authorization endpoint URI and changes the redirection to its own site.
4. Evil user tricks victim user to click on the link and authorize access (phishing or other social engineering attack).
5. Victim user thinking this is a valid authorization request, authorizes access.
6. Authorization server sends victim user back to the client, but since the redirection URI was changed, back to the evil user site.
7. Evil user grabs the code and exchanges it for an access token.

By checking that the callback URI used to deliver the code is the same as the one used to initiate the flow, the authorization server can verify that the user who initiated the flow is the same one to authorize access and finish the flow.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Freeman, Tim
> Sent: Wednesday, September 08, 2010 8:05 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Why give the redirect URI when trading an access
> code for an access token?
> 
> Hi.  I'm new here.  I searched the archives a bit and didn't immediately find an
> answer to my question below.  My apologies if there was some previous
> discussion of this that I missed.
> 
> Looking at the draft spec at http://tools.ietf.org/html/draft-ietf-oauth-v2-10,
> I see in section 4.1.1 "Authorization code" on page 22 that it is required to
> give the redirect_uri of the original request when exchanging an
> authorization code for an access token, and the authorization server must
> verify that the redirection URI is correct as well as the authorization code.
> Based on section 4.2 "Access Token Response" on page 25, it seems that the
> redirect_uri is not used when constructing the response from the
> authorization server.
> 
> So far as I can tell, the redirect_uri is useless in this request.  It does not
> contain any secrets.  The authorization code is verified and is meant to be an
> arbitrary unguessable identifier, so little is gained by verifying the
> redirect_uri also.  It is not used to construct the reply.  Why is it required?
> 
> Tim Freeman
> Email: tim.freeman@hp.com
> Desk in Palo Alto: (650) 857-2581
> Home: (408) 774-1298
> Cell: (408) 348-7536
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth