Re: [OAUTH-WG] Securing APIs with OAuth 2.0

Justin Richer <jricher@mitre.org> Tue, 06 March 2012 16:39 UTC

Return-Path: <jricher@mitre.org>
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 C31F321F8609 for <oauth@ietfa.amsl.com>; Tue, 6 Mar 2012 08:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.582
X-Spam-Level:
X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 34ntJCsFIXt6 for <oauth@ietfa.amsl.com>; Tue, 6 Mar 2012 08:39:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 885D221F85AD for <oauth@ietf.org>; Tue, 6 Mar 2012 08:39:48 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2AEEA21B0464; Tue, 6 Mar 2012 11:39:48 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1A28C21B0BD9; Tue, 6 Mar 2012 11:39:48 -0500 (EST)
Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 6 Mar 2012 11:39:47 -0500
Message-ID: <4F563D77.3050105@mitre.org>
Date: Tue, 6 Mar 2012 11:38:15 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Sergey Beryozkin <sberyozkin@gmail.com>
References: <B691F720-809F-4A9E-8C8E-6BF98EE68F07@appmuscle.com> <OF00AD6E13.25AA51DD-ON4A2579B4.00101F47-882579B4.00106E50@au1.ibm.com> <CAEwGkqD-1AkQHv47XVpA31NiQ2uTrTvptS0Pp0NqnL9LkvTcZw@mail.gmail.com> <4F54ABDB.1050702@gmail.com> <4F54CA3A.8020502@mitre.org> <CAOtGrG+5BM_JnsUUTxDJj7whfjXu3qo5Yg_zsA3ssfo+L8HH7w@mail.gmail.com>
In-Reply-To: <CAOtGrG+5BM_JnsUUTxDJj7whfjXu3qo5Yg_zsA3ssfo+L8HH7w@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.51]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0
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: Tue, 06 Mar 2012 16:39:51 -0000

> OK.
>
> Thanks for the explanations so far. It's very helpful.
>
> I'm prototyping the framework support for OAuth 2.0 and at this stage
> I'm trying to figure out what exactly the runtime itself can do and what
> has to be delegated to the custom code and thus how to design the api
> the runtime and the custom code will use to communicate with each other.

Makes sense. It's often hard to figure out exactly where to draw the 
lines of abstraction for fundamental libraries like this.

> Let me ask one more question, sorry if it's a silly one :-)
>
> So suppose a given client has been pre-authorized by the end user.
> Next, the client can get the pre-authorized token via the authorization
> code flow or the implicit code flow (ignoring the client_credentials one
> for the moment).
>
> Does it make sense to restrict which flow a given pre-authorized token
> can 'work' with ? Example, enforce that the pre-authorized token can
> only be issued to the clients initiating an authorization code flow but
> not to those trying an implicit one, or vice versa ?
>
> The reason I ask is that I'm thinking that the entity representing an
> access token should have a property indicating which grant type was used
> for this token being created in the first place. So if such a token
> were to represent the user pre-authorizing the client
> and then eventually given to a client via the authorization code or
> implicit code flow, then this token would actually need to
> be cloned each time for a specific grant type property be set, and
> this does not look optimal...

Several implementations that I've seen do restrict the flows that a 
given client is allowed to do. Any time you have a privileged client, 
such as one that's been auto-approved, it makes even more sense to lock 
it down in other avenues. You don't have to encode it into the token or 
code, but of course if you have a structured token format you may do 
that. Note that with the code flow, you probably don't actually generate 
the token until the client shows up with a valid code and client 
id/secret, but that's really a runtime optimization that's going to be 
specific for your setup.

All you really need is a flag at your AS that ties the given client id 
to a set of allowable grant types. When the client shows up at the AS 
endpoints, you look up this flag based on the client ID and verify that 
the flow you're doing matches up with what's allowed by configuration.

  -- Justin