Re: [OAUTH-WG] CORS and public vs. confidential clients

Bill Burke <bburke@redhat.com> Fri, 28 March 2014 16:52 UTC

Return-Path: <bburke@redhat.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E1E1A00D9 for <oauth@ietfa.amsl.com>; Fri, 28 Mar 2014 09:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnIh7Qdx-CTc for <oauth@ietfa.amsl.com>; Fri, 28 Mar 2014 09:51:58 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id A9AED1A00FB for <oauth@ietf.org>; Fri, 28 Mar 2014 09:51:58 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2SGptdf014127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 12:51:55 -0400
Received: from [10.10.60.86] (vpn-60-86.rdu2.redhat.com [10.10.60.86]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2SGpsTL008556; Fri, 28 Mar 2014 12:51:55 -0400
Message-ID: <5335A8AD.9030000@redhat.com>
Date: Fri, 28 Mar 2014 12:51:57 -0400
From: Bill Burke <bburke@redhat.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Prateek Mishra <prateek.mishra@oracle.com>
References: <53344407.1050802@redhat.com> <5334BB7B.2060602@oracle.com>
In-Reply-To: <5334BB7B.2060602@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zZwqmTlCgZFzCrnVehhures-8Lk
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] CORS and public vs. confidential clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 28 Mar 2014 16:52:01 -0000

The thread model doc was really great, but I still couldn't find 
anything concrete on what guarantees you lose if you use a public client 
vs. a confidential one.  Honestly, I'm just trying to have the right 
info to guide users on what auth flow to use and the pros/cons.

On 3/27/2014 7:59 PM, Prateek Mishra wrote:
> Bill - as you are referencing CORS in your message, I assume you are
> discussing a Javascript-only (browser) client. I believe the implicit flow
> was designed for this case and this flow never involves a confidential
> client.
>
Yes, it is a Javascript (browser) client.  Implicit flow doesn't allow 
for a refresh token.  Our browser javascript code uses CORS also when 
participating in the access code grant flow.

Our access codes are digitally signed, and unique.  They can only be 
turned into an access token once.  They are associated privately with a 
redirect URI, state, and client_id.  And they have a timeout.  We do 
validation/verification at each part of the flow to make sure the 
redirectURI, state, and/or client_id is valid.  I just want to know what 
to tell users what security implications there are if they use a public 
client in this scenario.

> Confidential clients may be used with the other flows (code,
> resource,..) that are capable of making a TLS call to a Token Endpoint.
>

BTW, Is there a better list for these types of questions?  Didn't have a 
lot of luck on the Google Group for OAuth.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com