Re: [OAUTH-WG] Strict equality matching of redirect_uri
Brian Eaton <beaton@google.com> Mon, 17 May 2010 17:49 UTC
Return-Path: <beaton@google.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 A4B5A3A69D8 for <oauth@core3.amsl.com>; Mon, 17 May 2010 10:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.468
X-Spam-Level:
X-Spam-Status: No, score=-104.468 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 MOQ3sOzQV+ra for <oauth@core3.amsl.com>; Mon, 17 May 2010 10:49:43 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 88D9B3A68DC for <oauth@ietf.org>; Mon, 17 May 2010 10:49:43 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o4HHnYvf009258 for <oauth@ietf.org>; Mon, 17 May 2010 10:49:34 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274118575; bh=uUaqrYdteQPYqK3+wbQMyv/CHvw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Q+/YXXnErd+IREYTV0yY728uaJQrJAaT0lF0E4oPsVFMObDAI4K+Ac7dLsGdvSbPx 9tD+2mSjnjMKy40FBhNUw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=ZsihNcXbUVG9lW+oTH9C0K+b6qu8LociRxiGx7u8TYWnfkjf9A/RhoXclR84dfJ26 1iBI3XRQjAuS92YSLcKAA==
Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by kpbe19.cbf.corp.google.com with ESMTP id o4HHnA5G005885 for <oauth@ietf.org>; Mon, 17 May 2010 10:49:33 -0700
Received: by pxi8 with SMTP id 8so2375260pxi.16 for <oauth@ietf.org>; Mon, 17 May 2010 10:49:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.21.19 with SMTP id y19mr3656951wfi.259.1274118573314; Mon, 17 May 2010 10:49:33 -0700 (PDT)
Received: by 10.143.136.7 with HTTP; Mon, 17 May 2010 10:49:33 -0700 (PDT)
In-Reply-To: <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com>
References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com> <AANLkTilCID4z-NjAJLMQ2GHcWHm-21fWKPzXs-6y4tyZ@mail.gmail.com> <AANLkTil8-AEe0Jjid2aKuI4IADCZ_vamNng5USnMKz8E@mail.gmail.com> <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com> <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com>
Date: Mon, 17 May 2010 10:49:33 -0700
Message-ID: <AANLkTikcUkd55549ZgVtzZ5EpkcKOveCULh7igqasqcO@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Dick Hardt <dick.hardt@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri
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: Mon, 17 May 2010 17:49:44 -0000
On Sun, May 16, 2010 at 11:20 AM, Dick Hardt <dick.hardt@gmail.com> wrote: > If the matching is left to an arbitrary, server defined algorithm, we lose > interop since a client implementation may make assumptions on what may be > allowed in the redirect_uri at one AS and then not be able to work with > another AS that is more restrictive. > As this is a security feature, I'd like to hear the options from the > security oriented participants with experience here. > Allen / Brian? We can do a session at IIW on this if people want. There are a few different use-cases to consider: - installed applications using the js profile or the web app profile It doesn't matter what you do, you can't authenticate the installed application. My recommendation here is to do something like what we've done with OAuth for installed apps [1]. - registered web apps with a secure client-secret You can allow *any* callback URL on the redirect. The callback URL is authenticated using the client-secret. We should all do strict equality matching when exchanging the verification code for refresh token and access token. - js profile, or web app profile where you don't completely trust the registration or the security of the client-secret We've got lots of service-provider specific behavior here. Unfortunately most service providers don't seem to be willing to change (or in some cases even document) what they are doing. So we're doomed unless we can get consensus from service providers that there needs to be consensus. =) Logic I've seen includes: - regular expressions - any callback URL on the fully-qualified hostname - any callback URL on a domain name. - fixed callback URL path, arbitrary callback URL query - fixed callback URL path, fixed callback URL query, one query parameter (wrap_state, or whatever we called it =) allowed to vary - any callback URL path under a particular directory I tried to summarize the risks in the security considerations I wrote up a few weeks ago. Check out the section on "Authentication Techniques" and "Web App Delegation Profile - Security Considerations". Cheers, Brian [1] http://code.google.com/apis/accounts/docs/OAuthForInstalledApps.html [2] http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
- [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt Torsten Lodderstedt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Dick Hardt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Dick Hardt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Torsten Lodderstedt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Torsten Lodderstedt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Evan Gilbert
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Evan Gilbert
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Strict equality matching of redire… Luke Shepard
- Re: [OAUTH-WG] Strict equality matching of redire… Raffi Krikorian
- Re: [OAUTH-WG] Strict equality matching of redire… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Axel.Nennker
- Re: [OAUTH-WG] Strict equality matching of redire… Dick Hardt
- Re: [OAUTH-WG] Strict equality matching of redire… Evan Gilbert
- Re: [OAUTH-WG] Strict equality matching of redire… Marius Scurtescu
- Re: [OAUTH-WG] Strict equality matching of redire… Brian Eaton
- Re: [OAUTH-WG] Strict equality matching of redire… Evan Gilbert