Re: [OAUTH-WG] redirect uri validation

Eran Hammer-Lahav <eran@hueniverse.com> Sun, 04 September 2011 22:13 UTC

Return-Path: <eran@hueniverse.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 05E0B21F8AB9 for <oauth@ietfa.amsl.com>; Sun, 4 Sep 2011 15:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.257
X-Spam-Level:
X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_102=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cXqctHDOQzQ for <oauth@ietfa.amsl.com>; Sun, 4 Sep 2011 15:13:11 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5CFED21F8ACA for <oauth@ietf.org>; Sun, 4 Sep 2011 15:13:11 -0700 (PDT)
Received: (qmail 13903 invoked from network); 4 Sep 2011 22:14:52 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 22:14:52 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 4 Sep 2011 15:14:52 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Sun, 04 Sep 2011 15:13:01 -0700
Thread-Topic: [OAUTH-WG] redirect uri validation
Thread-Index: AcxbjCpSWRw59kJJSwGr4PITrEZuDgPwu/VA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <fcffd9492cbaced09c93f4e3c37b569f@lodderstedt-online.de> <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DAAEA.7090304@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E498313.3080009@lodderstedt.net>
In-Reply-To: <4E498313.3080009@lodderstedt.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>, "eran@sled.com" <eran@sled.com>
Subject: Re: [OAUTH-WG] redirect uri validation
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, 04 Sep 2011 22:13:12 -0000

That's not complete. A valid redirection URI is not enough to verify client identity at the time it is presented, but it is enough in many cases to prevent leaking credentials later on.

How about a slight change:

          A valid redirection URI is not sufficient to verify the client's identity when asking for
          end-user authorization, but can be used to prevent delivering credentials to a
          counterfeit client after obtaining end-user authorization.

EHL

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Monday, August 15, 2011 1:36 PM
> To: Eran Hammer-Lahav
> Cc: eran@sled.com; oauth@ietf.org
> Subject: Re: [OAUTH-WG] redirect uri validation
> 
> Hi Eran,
> 
> Am 15.08.2011 08:57, schrieb Eran Hammer-Lahav:
> > Added to 1.4.2:
> >
> >              When issuing an implicit grant, the authorization server does not
> authenticate the
> >              client and [[in some cases]], the client identity [[can]] be verified via
> the redirection URI
> >              used to deliver the access token to the client. The access token may
> be exposed to the
> >              resource owner or other applications with access to the resource
> owner's user-agent.
> >
> > Hope this is sufficient.
> 
> What do you want to express? Clients can sometimes be verified via
> redirection URI?
> 
> My intention was to point out that an invalid redirect URI is a counter-
> evidence for a client's identity but a valid redirect URI is _not_ an evidence
> for its identity.
> 
> I would suggest to add the text below to section 10.1., last paragraph after
> the sentence
> 
> "For
>     example, by requiring the registration of the client redirection URI
>     or enlisting the resource owner to confirm identity."
> 
> proposed text:
> 
> Please note: while an invalid redirection URI indicates a counterfeit client, a
> valid redirection URI is not sufficient to confirm a client's identity.
> 
> regards,
> Torsten.
> 
> 
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Eran Hammer-Lahav
> >> Sent: Sunday, August 14, 2011 11:09 PM
> >> To: Torsten Lodderstedt
> >> Cc: torsten@lodderstedt-online.de; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] redirect uri validation
> >>
> >> Where would you suggest I add this?
> >>
> >> EHL
> >>
> >>> -----Original Message-----
> >>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> >>> Sent: Monday, July 25, 2011 10:42 AM
> >>> To: Eran Hammer-Lahav
> >>> Cc: torsten@lodderstedt-online.de; oauth@ietf.org
> >>> Subject: Re: [OAUTH-WG] redirect uri validation
> >>>
> >>> Hi Eran,
> >>>
> >>>>>> OAuth 1.0 was highly criticized for failing to address client
> >>>>>> identity in public clients. I believe OAuth 2.0 offers a much
> >>>>>> better story, within the boundaries>of what’s possible today.
> >>>>> Agreed. I think we must honestly discuss the value of client
> >>>>> authentication/identification itself. I personally think it is
> >>>>> over-emphazised right now. The strength of OAuth 2.0 is that it
> >>>>> allows solutions where neither client nor resource server have
> >>>>> access or
> >>> do store end-user credentials.
> >>>>> Client authentication is nice but not the main feature.
> >>>> Do you have any specific suggestions not already mentioned on the
> list?
> >>> I would suggest to mention that while an invalid redirect_uri
> >>> indicates a counterfeit clients a valid redirect does not prove the
> >>> calling
> >> client's identity.
> >>> regards,
> >>> Torsten.
> >>>
> >>>
> >>>> EHL
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth