Re: [OAUTH-WG] Oauth Server to Server

Sergey Beryozkin <sberyozkin@gmail.com> Fri, 27 September 2013 08:48 UTC

Return-Path: <sberyozkin@gmail.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 93DBA21F9998 for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2013 01:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 pAjes+m0z7us for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2013 01:48:54 -0700 (PDT)
Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3121F9798 for <oauth@ietf.org>; Fri, 27 Sep 2013 01:48:54 -0700 (PDT)
Received: by mail-ee0-f46.google.com with SMTP id c13so1054310eek.19 for <oauth@ietf.org>; Fri, 27 Sep 2013 01:48:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cjVYYJzXNt9nHn9/CW2/M/I+N/9IywDe8N6LNMJBj+A=; b=RGu90JLg/UBmivaAVH4PZzjFxpf+NgZOyyhygxDVDIFKc77r+L59BezTKBrpDOloed 1Y9m86tpTwYWOejuL9rPibnE5dc34brsL9pCt622plVbEhIqJj/CFFHP2NYmfEhzy7mW 9m64nNh69lXK1xlhgkTAKmtGTQe9LJXjPYWjs+YEP61EYs9yzmORXdcPeQu5ETpFDtjV dbVRskmmFU+xj+Cb98JYeW562DmDMRWQuFbKcn3NxVEMn/Npry9QFMfCq/vSxTV3UhUN emdWyNw+7JQNPbSGZ585A4q2DnZg3OXW/T6CYIBcbY9iIfcWwCMq8DDXc+On+W/gbHen m8ww==
X-Received: by 10.14.210.195 with SMTP id u43mr671916eeo.80.1380271733707; Fri, 27 Sep 2013 01:48:53 -0700 (PDT)
Received: from [10.36.226.2] ([217.173.99.61]) by mx.google.com with ESMTPSA id a43sm13602730eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 01:48:52 -0700 (PDT)
Message-ID: <52454668.8060904@gmail.com>
Date: Fri, 27 Sep 2013 09:48:40 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Antonio Sanso <asanso@adobe.com>
References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <524429D2.3010008@gmail.com> <04F773FD-E099-4FB6-9BB0-6E5F910EA205@adobe.com>
In-Reply-To: <04F773FD-E099-4FB6-9BB0-6E5F910EA205@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Oauth Server to Server
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: Fri, 27 Sep 2013 08:48:55 -0000

On 27/09/13 09:33, Antonio Sanso wrote:
>
> On Sep 26, 2013, at 2:34 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
>
>> On 24/09/13 13:08, Antonio Sanso wrote:
>>> Hi *,
>>>
>>> apologis to be back to this argument :).
>>>
>>> Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :)
>>>
>>> At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant.
>>>
>>> Let me tell I am not a big fun of this particular flow :) (but this is another story).
>>>
>>> An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1].
>>
>> 2-way TLS and Resource Owner Password Credentials should be secure
>> enough, right ?
>>
>
> secure is secure what I do not like of that flow though is the fact that the resource owner should give the AS username/password to the client
>
Sure I agree to some extent; FYI, the integration scenarios I've been 
aware of (ex, Big Query server to server with no user having to sit in 
front of the application, with the application design being driven from 
a tooling studio) would work IMHO perfectly well with RO grant due to 
the clients & resource owners being most likely in the same 
organization; working with a json token complicates things quite a lot 
in our particular case :-), obviously it is more secure on the Web at 
large,

Cheers, Sergey

> regards
>
> antonio
>
>> Cheers, Sergey
>>>
>>> Couple of more things:
>>>
>>> - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>>> - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft??
>>>
>>> Thanks and regards
>>>
>>> Antonio
>>>
>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>> _______________________________________________
>>> 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
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com