Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Neil Madden <neil.madden@forgerock.com>
In-Reply-To: <CAD9ie-uQGEwpOEhR2fVT_teCn=xXze2Hz5p23S4mY0GmuJJYkw@mail.gmail.com>
Date: Tue, 23 Jul 2019 11:10:11 +0100
Cc: Aaron Parecki <aaron@parecki.com>,
 oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F6A8E4E-3574-4666-A561-D67D5D0B2EA9@forgerock.com>
References: <BD2D90C8-B629-4955-A22C-6E80E6390EEE@mit.edu>
 <CAGBSGjr+kfiavvzhPDF2SaBLDAjusoOGjvgTA85FadM+s_2u=A@mail.gmail.com>
 <E041DFD5-0501-471E-94B3-D1B36595F0BB@forgerock.com>
 <CAD9ie-smP4dyMPQAuMvD8AxXV1KNuLwBuYFRPtQDVCRBKkd-2A@mail.gmail.com>
 <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com>
 <CAD9ie-uQGEwpOEhR2fVT_teCn=xXze2Hz5p23S4mY0GmuJJYkw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9kT7aCacb02i-7g90vXwig3Fiy4>
Subject: Re: [OAUTH-WG] Transaction Authorization
Precedence: list

If we follow the principle of least authority then a token should be =
scoped as narrowly as possible to a particular resource =
server/resource/time period/transaction. The security topics BCP has =
already gone quite far down this path in its recommendations: =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.=
3 . Least privilege naturally leads to clients needing more tokens, so =
we should make obtaining (and using) multiple tokens as frictionless as =
possible.

For an example of this, see the work done by my colleagues to simplify =
juggling multiple access tokens for different resource servers - =
https://www.npmjs.com/package/appauthhelper . The library allows the =
developer to specify which scopes are used for which RS:

    resourceServers: {
        "https://login.example.com/oauth2/userinfo": "profile",
        "https://rs.example.com/": "rs_custom_scope"
    },

The library then takes care of making multiple requests to get =
appropriately-scoped access tokens and then attaching them to =
appropriate requests. But the more resource servers you need to access, =
the more tokens you need and the more requests you have to make. There =
is therefore currently a "tax" on least privilege use of access tokens =
as it is all on the client to juggle these requests, giving an incentive =
for clients to instead request Big Tokens that grant lots of authority =
in a single request/response.

-- Neil


> On 22 Jul 2019, at 22:46, Dick Hardt <dick.hardt@gmail.com> wrote:
>=20
> Hi Neil
>=20
> I see that you are looking at how to modify Justin's proposal, and I'm =
looking at what are the requirements.
>=20
> Ignoring the specifics, is there a reason why multiple tokens need to =
be returned in the same request?
>=20
>=20
> On Mon, Jul 22, 2019 at 9:41 AM Neil Madden =
<neil.madden@forgerock.com> wrote:
>=20
>> On 21 Jul 2019, at 22:22, Dick Hardt <dick.hardt@gmail.com> wrote:
>>=20
>> Hi Neil, I agree that an access token that is usable across resources =
is problematic.
>>=20
>> How are you thinking multiple access tokens would be returned?
>=20
> Well there are lots of possible ways, e.g.:
>=20
> {
> "tokens": [
>     { "resource": "https://res1", "access_token": "..." },=20
>     { "resource": "res2", ...}, ...
> ]
> }
>=20
> I'm not particularly wedded to any format.
>=20
>> Why do you think the request needs to return multiple tokens rather =
than making a separate request for each token? That would seem to =
simplify the request and response as context would only need to provided =
for the one access token.
>=20
> Note that in Aaron's proposal we have a "user" section on (presumably) =
every access token response, which indicates a userinfo endpoint that =
itself needs an access token. So either the same access token is used to =
access that userinfo endpoint (which means that the RS can also access =
the userinfo endpoint), or else we already need to return a second =
access token in the same request, e.g.:
>=20
> {
>       "access_token": {
>         "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>         "type": "bearer"
>       },
>       "user": {
>         "id": "5035678642",
>         "userinfo": =
"https://authorization-server.com/user/5035678642",
>         "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk"
>       }
>     }