Re: [OAUTH-WG] Auth Server / Resource Server Coordination

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 13 October 2015 08:40 UTC

Return-Path: <vladimir@connect2id.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 BC7A11A1A7C for <oauth@ietfa.amsl.com>; Tue, 13 Oct 2015 01:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 MdaP4a--P3Vw for <oauth@ietfa.amsl.com>; Tue, 13 Oct 2015 01:40:07 -0700 (PDT)
Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874971A1A72 for <oauth@ietf.org>; Tue, 13 Oct 2015 01:40:07 -0700 (PDT)
Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa11-02.prod.phx3.secureserver.net with id UYg51r00A15ZTut01Yg6DZ; Tue, 13 Oct 2015 01:40:07 -0700
To: oauth@ietf.org
References: <CABPN19_wYVEvqEU85FDZMYe6k8E8qkL0gGDvFeQMXaaQt+yAbQ@mail.gmail.com> <2064190583.2714607.1444710048221.JavaMail.yahoo@mail.yahoo.com> <CABPN19_VCKzuQCfFHV=C6LjHDVUghmMgkz9dW-3iH8fscBGD4Q@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <561CC364.1090206@connect2id.com>
Date: Tue, 13 Oct 2015 11:40:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CABPN19_VCKzuQCfFHV=C6LjHDVUghmMgkz9dW-3iH8fscBGD4Q@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/YGQS08s5MnPrRysUsc1h8W2kCK0>
Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Oct 2015 08:40:08 -0000


On 13.10.2015 07:37, Ofer Nave wrote:
>> You do have decisions to make on whether you use symmetric crypto or PK
> there.
>
> That's another thing I was pondering -- simple shared secret, or require
> generated a private/public key pair.
>
> The asymetric form is a little more complicated in terms of the user
> experience.  Is there a practical reason to prefer it?

If the AS and the Resource Servers (RS) share a secret, there is a risk
of an RS impersonating authorised clients by creating valid tokens to
access other RSs.

You may prevent this by making sure every RS gets its own secret, but in
that case you cannot issue tokens with multiple RS audiences.

With asymmetric keys you won't have these problems. The RS would only
need to have a copy of the public AS key to verify the tokens.


Vladimir

-- 
Vladimir Dzhuvinov