[OAUTH-WG] public clients and token exchange

Bill Burke <bburke@redhat.com> Mon, 02 April 2018 22:55 UTC

Return-Path: <bburke@redhat.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 4303212DA15 for <oauth@ietfa.amsl.com>; Mon, 2 Apr 2018 15:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5QsAcIWK4ZWb for <oauth@ietfa.amsl.com>; Mon, 2 Apr 2018 15:55:22 -0700 (PDT)
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533D31252BA for <oauth@ietf.org>; Mon, 2 Apr 2018 15:55:22 -0700 (PDT)
Received: by mail-vk0-f52.google.com with SMTP id m69so7151683vka.8 for <oauth@ietf.org>; Mon, 02 Apr 2018 15:55:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ictT4EaRRky7Md0BsGbNuQ9j9GaFHd2LJpaK2m6VMgM=; b=VAViRHAbVd8AvXG8GKDXsLqGKrpUIgt6LVYgaPvT7ltU/ndaiU6dt9IYi7vrVGeftU KspRdjC++45PkQgavTKTeVt5fCxbWwseYKvuJL4fmQLWko0VJJeackoXzNSwNtzjEApu /6dIL3G/tadxHTeyUm7dnKdiQQ44Iuh+S9wIsgZYVlsWdnXuMkNu1MkDP3/AS025QESi kBzwe00RjBNZPjMUqct5u179j4dH0ffGgiR8EwNDNmL9xE7YaRHMZY9bupthZco7R4h0 3Vs+ahwPEK/o1LMh9d1LfDd+o0IZJK+r1cvDd2kMT6rE1RaiJMjci35Fj4I9jEmD3Orc 5sUQ==
X-Gm-Message-State: ALQs6tA6ZS3oLt+7UTAsb8oW4KsVQ+o16iOUxrDo7gZT0vgzzE0hWLR6 mYMTWFeLIPlxC/QCcrUlRDLJzwQ6GPdqWzn7JXL/4A==
X-Google-Smtp-Source: AIpwx49w11yaum4GnHswoyTaoMR85WiciTogba/XO8v1MrQKycM+aOVkqrYLoGCMBSItnQHaM7FfnGT9UHL8FfRwijE=
X-Received: by 10.31.165.3 with SMTP id o3mr4648015vke.76.1522709721073; Mon, 02 Apr 2018 15:55:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.201.149 with HTTP; Mon, 2 Apr 2018 15:55:20 -0700 (PDT)
From: Bill Burke <bburke@redhat.com>
Date: Mon, 02 Apr 2018 18:55:20 -0400
Message-ID: <CABRXCmx9hiFRQtU-vCbOZodLYdNp=t1RQNoYRYmpUA9=BKkdWw@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OX3ziT1KbqD5odtk5LZwm_RfORk>
Subject: [OAUTH-WG] public clients and token exchange
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 02 Apr 2018 22:55:24 -0000

We have a need for public clients to perform token exchanges.  Anybody
have any recommended policies for this?  I'm worried about untrusted
services obtaining a bearer token that they can exchange for upgraded
permissions.  The Auth Server has to put a lot of trust in the public
client to do the right thing.

What should be the initial access token the public client gets?

1) One approach is that it receives an access token devoid of
privileges.  This forces the public client to request an exchange
before invoking on anything.  Then what should be the validation
policy with teh Auth Server?  Do not allow upgrading of token unless
the token being exchanged has zero scopes/audiences?

2) Another approach is that the initial access token has all privilges
the public client needs and the public client downgrades the token
before performing invocations.  The auth server only needs to check
that the client is asking for a downgrade.

3) The last approach we are considering is a combination of #1 and to
only allow public clients to exchange a refresh token.  Being in
possession of a refresh token means that the public client has been
involved with a code to token flow, or a password credentials grant.
For code to token, this means the public client had a valid redirect
uri.  For password credentials grant, the client was trusted enough to
obtain user credentials.






-- 
Bill Burke
Red Hat