The 'aud' parameter can be multi-value ... as long as it is advertised
that there are advantages and drawbacks to do so.
The advantage is that a single token can be consumed by more than one
server.
The drawback is that one of these servers, depending how the access
token is protected, might be able to re-use
the token towards one of these other servers. This may be desirable of
some cases, but not necessarily.
These advantages and drawbacks should be advertised in the main body of
the document and/or in the security
considerations section.
According to the content of RFC 7800:
The "aud" (audience) claim identifies the recipients that the JWT is
intended for.
The interpretation of audience values is application specific.
So the 'aud' parameter is not necessarily a" mix of logical names and
physical locations".
If a fixed value is being used, e.g. a URL of the server, then the
authorization server can easily know where the access tokens
will be used and thus is in a position to act as Big Brother. It is thus
recommended to use a different value in the aud claims
for each access token that contains no semantics in it but that the
resource server can easily recognize.
This should be advertised in a privacy considerations section.
Denis
There are cases where tokens are supposed to be consumed at multiple
places and the `aud` needed to capture them. That's why `aud` is a
multi-valued field.
On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones
<michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com>>:
For the same reason that the “aud” claim is multi-valued in JWTs,
the audience needs to stay multi-valued in Token Exchange. Ditto
for resources.
Thanks,
-- Mike
*From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of
*Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*To:* Torsten Lodderstedt <tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>
*Cc:* oauth <oauth@ietf.org <mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] I-D Action:
draft-ietf-oauth-token-exchange-07.txt
Thanks for the review and question, Torsten.
The desire to support multiple audience/resource values in the
request came up during a review and discussion among the authors
of the document when preparing the -03 draft. As I recall, it was
said that both Salesforce and Microsoft had use-cases for it. I
incorporated support for it into the draft acting in the role of
editor.
From an individual perspective, I tend to agree with you that
allowing for multiple audiences/resources adds a lot of
complexity that's like not needed in many (or most) cases. And I
would personally be open to making audience and resource mutual
exclusive and single valued. A question for the WG I suppose.
The "invalid_target" error code that was added in -07 was
intended to give the AS a standard way to deal with the
complexity and reject request with multiple audiences/resources
that it doesn't understand or is unwilling or unable to process.
It was intended as a compromise, of sorts, to allow for the
multiples but provide an easy out of saying it can't be supported
based on whatever implementation or policy of the AS.
On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
Hi Brian,
thanks for the clarification around resource, audience and
scope.
Here are my comments on the draft:
In section 2.1 it states: „Multiple "resource" parameters may
be used to indicate
that the issued token is intended to be used at the multiple
resources listed.“
Can you please explain the rational in more detail? I don’t
understand why there is a need to ask for access tokens,
which are good for multiple resources at once. This is a
request type more or less exclusively used in server to
server scenarios, right? So the only reason I can think of is
call reduction.
On the other side, this feature increases the AS's
complexity, e.g. its policy may prohibit to issue tokens for
multiple resources in general or the particular set the
client is asking for. How shall the AS handles such cases?
And it is getting even more complicated given there could
also be multiple audience values and the client could mix them:
"Multiple "audience" parameters
may be used to indicate that the issued token is intended to be
used at the multiple audiences listed. The "audience" and
"resource" parameters may be used together to indicate multiple
target services with a mix of logical names and physical
locations.“
And in the end the client may add some scope values to the
„meal“, which brings us to
„Effectively, the requested access rights of the
token are the cartesian product of all the scopes at all the
target
services."
I personally would suggest to drop support for multiple
audience and resource parameters and make audience and
resource mutual exclusive. I think this is sufficient and
much easier to implement.
kind regards,
Torsten.
Am 11.01.2017 um 20:04 schrieb Brian Campbell
<bcampb...@pingidentity.com
<mailto:bcampb...@pingidentity.com>>:
Draft -07 of "OAuth 2.0 Token Exchange" has been
published. The primary change in -07 is the addition of a
description of the relationship between
audience/resource/scope, which was a request or comment
that came up during the f2f meeting in Seoul.
Excerpted from the Document History:
-07
o Fixed typo (desecration -> discretion).
o Added an explanation of the relationship between
scope, audience
and resource in the request and added an
"invalid_target" error
code enabling the AS to tell the client that the
requested
audiences/resources were too broad.
---------- Forwarded message ----------
From: <internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action:
draft-ietf-oauth-token-exchange-07.txt
To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
Cc: oauth@ietf.org <mailto:oauth@ietf.org>
A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Web Authorization
Protocol of the IETF.
Title : OAuth 2.0 Token Exchange
Authors : Michael B. Jones
Anthony Nadalin
Brian Campbell
John Bradley
Chuck Mortimore
Filename : draft-ietf-oauth-token-exchange-07.txt
Pages : 31
Date : 2017-01-11
Abstract:
This specification defines a protocol for an HTTP- and
JSON- based
Security Token Service (STS) by defining how to
request and obtain
security tokens from OAuth 2.0 authorization servers,
including
security tokens employing impersonation and delegation.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07
Please note that it may take a couple of minutes from the
time of submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org/>.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
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
