IETF Logo Mail Archive

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

v2.23.0 | Report a Bug | By Email