Thanks Annabelle and George! I am consolidating replies to both your latest
comments in this mail. This seems a hard rock to lift, but it also seems to be
the last one 😊.
The TL;DR is, I am not completely opposed to relaxing the constraints and
turning them into security considerations, but I think we’d miss an opportunity
to make things clearer for developers. At the same time I wouldn’t want to make
this profile too patronizing, hence I appreciate the opportunity to discuss.
[Annabelle]
>. There may be no "scope" parameter. The "scope" parameter is OPTIONAL in
authorization requests. So an AS/RS operator could decide they're going to omit "scope" entirely and
use multiple resource parameters instead. Since there are no scopes, there is no opportunity for confusion.
I am a BIG fan of ATs with no scope- all the scenarios where there’s no
delegation (1st parties etc) shouldn’t use scopes at all. The current language
in the profile does allow for scope-less ATs, and given that the goal is to
prevent confusion, I agree that there’s no need to restrict the audience to one
single resource if there are no scopes at all to misinterpret.
I would be in favor to allow multiple resources in audience in that case.
Unfortunately it’s not as simple as just saying “If the incoming request
incudes multiple resource indicators and no scope, accept it and use the
incoming resource indicators list as aud value” – mostly because there is a
very large number of production systems where the request includes no scopes
and one resource indicator, but the resulting token includes a collection of
scopes the user already consented to for that resource- but I am sure we can
get to acceptable language that expresses the concept “if there are multiple
resource indicators in the request and the rest of the rules in S.3 the
resulting AT won’t contain a scope claim, the resulting AT must use that
resource indicators list as aud value”.
An AS/RS operator may use "scope" to indicate a role or policy (or set of policies) that the client wants,
and allow the client to narrow their permissions using "resource" parameters. This would allow the client to
obtain narrowly scoped access tokens for specific use cases without needing to define separate roles/policies for each.
In this case, a JWT AT with a multi-valued "aud" claim and a "scope" claim would seem appropriate,
as the scope claim is intended to apply to all of the audience values.
I agree that deployments like the one you describe might exist, in fact I am
sure they do. However it seems really a brittle approach, given that it makes a
specific assumption (scopes are valid across all the resources) that isn’t
enshrined anywhere and if future updates to that deployment violate that
assumption, that would lead to the scope confusion the current language in the
profile is trying to prevent. We offer very little guidance in that respect:
the main place were multiple resources are even mentioned is resource
indicators, and all the samples (I know, non-normative) use scopes
unambiguously tied to a specific resource (more on that later) making the
multi-resource scope even more of a special case.
Stepping back a bit - the intent behind those resource-scope restrictions is to
provide a bit more guidance on scopes and resources than we did in the past,
and narrowing the range of cases developers would need to take into account
when implementing the profile.
In my experience the lack of more prescriptive guidance led to deployments and
interpretations that, while remaining fully within the boundary of what the
spec allows, are often questionable from the security and arch perspective.
(*)I acknowledge that I might be swinging too far in the opposite direction,
and perhaps a similar effect could be achieved by adding an “Authorization
Considerations” section where implementers are warned about the danger of scope
confusion rather than downright forbidding multi resources audiences when
including scopes as well. I still like the simplicity and clarity of the
current restriction, but of course I am open to feedback.
The mapping between audience and scope may be unambiguous. There are a lot of deployments
to which the blast radius risk you're trying to address by requiring "aud"
simply does not apply
There are certainly cases where scope strings unambiguously map to specific
resources, but once again, that’s a strong assumption to make and one I feel
cannot be made lightly. Resource indicators use very simple examples (contacts,
calendar) that are hard to generalize to scenarios where the number and
lifecycle of resources truly calls for the use of indicators identifying a
resource in a large multitenant system usually entails large identifiers, and
stuffing those in the scope to prevent ambiguity can be expensive from both
provisioning and token, request size angles.
It may seem innocuous to require these deployments to explicitly include a broad audience like
"api.example.com" anyway, that can lead to implementers ignoring the requirement (leading
to interop issues), not validating it (also leading to interop issues or security issues if the
deployment wants to start actually using it for real), or doing something funky with it since there
isn't anything "real" that the value needs to conform to.
Every spec guidance risks not being followed. But in this particular case, use
of a logical audience is quite mainstream – we had a similar discussion for
resource indicators and that’s why the spec ended up including logical
identifiers as one of the resource parameter flavor. “real” is a relative term,
given that there are already many different ways in which a logical resource
might map to different “physical” artifacts (see heroku’s late binding URLs).
Collective audiences are in common use for poor man’s trusted subsystems: not
endorsing the approach, but bringing circumstantial evidence that broad
audiences aren’t that uncommon or hard to grok for developers already today.
Finally, turning off validation is actually not that trivial in many SDKs,
given that they mostly reuse/derive from OIDC and the audience check is
mandatory: I saw more often people disabling iss check than aud. None of this
means that the errors you describe cannot happen: but I think they aren’t more
likely than any other guidance in the spec.
I do ack the more generic point that, like in the preceding case, this might
suggest that the current guidance is too strict- see (*)
[George]
I think one of the problems we have in being super specific about how the JWT
access token is constructed is that is means it's not possible for many
organizations to follow. How scopes are implemented is very varied across
deployments which means that some may conform to the perspective of the spec
and many may not.
You are right, the spec is an opinionated take- I agree that many
organizations used scopes in very different ways, and I think it is the result
of giving very little guidance on scopes and resources, with the consequence
that some choices might have been less wise than others.
With the current guidance I attempted to capture a narrower set of scenarios
where some of the most obvious issues (like scope confusion) can be averted,
while still satisfying most of the cases I observed in the sample JWT ATs: I am
not trying to overindex on those cases, and I don’t mean to imply that the
profile should strictly follow those, but in the spirit of eliminating
ambiguity as much as possible, this single resource narrowing seemed a solid
core to build robust implementations on- fully aware of the fact that many
current implementations would not conform (tho I am not sure how many
implementations already adopted resource indicators or equivalent).
In any case, see (*)- I think I can be convinced to turn the current
restrictions into security/authorization considerations- but I would
reluctantly do so as I think we’d perpetuate a lot of the ambiguity we have in
this space today.
Personally, I'm not a big fan of trying to use scopes for fine-grain
authorization. I don't think that is what they were intended for when
originally designed. (This can be seen by the RAR spec introducing a completely
different way of specifying fine-grain authorization context.) Even in
multi-tenant systems, I don't see issues with using sub-resource scopes as each
tenant should define the scopes that make sense for that tenant. I don't think
the AS needs to understand the scopes, just provide a mechanism to issue the
correct scope under user consent to the client and let the RS apply the
authorization policy when it gets the scopes out of the token.
I am not crazy about that either- especially given that when fine grained authZ
is involved very, very often what developers really want are user privileges
and scopes are just abused in lieu of privileges simply because the spec
doesn’t address the non-delegation scenario hence a screwdriver ends up being
used as a hammer.
Nonetheless, if scopes are used- mandating that every scope is tied to the
resource does lead to huge tokens and significant management overhead if you
have lots of resources whose identifier must be globally unique,
nonreassignable etc etc hence very large – and the AS doesn’t need to
understand the semantic of each scope but it does need to know whether a scope
can be requested for a given resource, plus any policy the admin might want to
execute at token issuance time (eg this scope requires 2FA) hence juggling
large numbers of large strings can be hard for the AS – and RS. In any case,
the use of multiple resources in the aud in the wild appeared to be very rare,
hence even if there would be a foolproof way of defining a resource-scope
mapping, I would not spend cycles defining it here… and leaving it as exercise
for the reader wouldn’t work per the above. As in (*) we could relax the
constraint here and just warn people against scope confusion, but I feel we’d
be missing an opportunity.
------
On 3/24/20, 17:00, "Richard Backman, Annabelle" <richa...@amazon.com> wrote:
To borrow a term from ML, I think the "aud", "scope", and resource
indicator-related text is overfitted to a specific set of deployment scenarios, and a specific way
of using scopes and resource indicators.
Consider the following:
1. There may be no "scope" parameter
The "scope" parameter is OPTIONAL in authorization requests. So an AS/RS operator could decide they're going to
omit "scope" entirely and use multiple resource parameters instead. Since there are no scopes, there is no opportunity
for confusion. In this case, a JWT AT with a multi-valued "aud" claim and no "scope" claim would seem
appropriate. While multiple resource indicators could be pushed into a single scope string, this introduces opportunities for
serious security impacting encoding/decoding/parsing bugs. The more I think about it, the more "I don't have to deal with
parsing a scope string" seems like a compelling reason to go this route... __
2. The scopes may apply to all audiences
An AS/RS operator may use "scope" to indicate a role or policy (or set of policies) that the client
wants, and allow the client to narrow their permissions using "resource" parameters. This would allow the
client to obtain narrowly scoped access tokens for specific use cases without needing to define separate roles/policies
for each. In this case, a JWT AT with a multi-valued "aud" claim and a "scope" claim would seem
appropriate, as the scope claim is intended to apply to all of the audience values.
3. The mapping between audience and scope may be unambiguous
There are a lot of deployments to which the blast radius risk you're trying to address by requiring
"aud" simply does not apply. It may seem innocuous to require these deployments to explicitly
include a broad audience like "api.example.com" anyway, that can lead to implementers ignoring the
requirement (leading to interop issues), not validating it (also leading to interop issues or security issues
if the deployment wants to start actually using it for real), or doing something funky with it since there
isn't anything "real" that the value needs to conform to.
–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
On 3/24/20, 3:31 PM, "OAuth on behalf of Vittorio Bertocci"
<oauth-boun...@ietf.org on behalf of vittorio.bertocci=40auth0....@dmarc.ietf.org> wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
Thanks George for the super thorough review and feedback!
Inline
> Section 1. Introduction
��� second line: scenario should be plural --> scenarios
��� second sentence: "are not ran by" --> "are not run by"
�� cofidentiality --> confidentiality
Fixed. Thanks!
> Section 2.2.1 Authentication Information Claims
��� I'm not sure that this definition of `auth_time` allows for
the
case where a user is required to solve an additional challenge.
If the challenge entails going back to the AS, then I believe the language
(in the initial paragraph of 2.2.1 and in auth_time itself) accommodates for
that and does require the auth_time to be updated.
If you hit the AS and present an authentication factor (such as your
challenge) and obtain a new token in the process, the auth_time will reflect
the time of your latest authentication just like an id_token would in the same
circumstances (think protected route in a web app requiring step up auth) and
(likely) associated session artifacts (think RTs or cookies with sliding
expiration, the challenge would count as activity and move the expiration).
> ��� I think there is a difference between session_start_time
and last
auth_time. This feels more like it's defining the session_start_time
concept.
> �� These same issues can apply to the `acr` and `amr` values as
well.
Per the above, the intent is more to express the last time the user
performed any authentication action rather than the start time. The intent is
to provide information as current as possible, as it might be relevant to the
RS decisions whereas the history before current conditions might not be
consequential.
> �� Even if for this secondary challenge a new refresh_token is
issued,
it is unlikely many relying parties will want to treat that as issuing
a
new session. The goal is to keep the user logged in to a single
session.
Could you expand on the practical implications of the above? The intent
isn't as much to reflect session identifying information per se, but to provide
the RS with the most up to date information about the circumstances in which
the current AT was obtained. The fact that a session was initially established
using acr level 0 doesn’t really matter if the AT I am receiving now has been
obtained after a stepup that brought acr to 1, if my RS cares auth
authentication levels my authorization decision shouldn't be influenced by
whether somewhere the session artifact didn’t change its sessionID after the
stepup. Same for acr, auth_time
> Section 2.2.3 Authorization Claims
�� I find the statement "All the individual scope strings in the
scope
claim MUST have meaning for the resource indicated in the aud claim"
somewhat problematic. In many deployments today for 1st party clients
to
the authorization server and taking into account mobile applications,
the access token most like contains scopes for many of the 1st party
backend APIs. It's possible to get around this by setting the 'aud'
claim to something like "com.example.apis" and hence all the issued
scopes map to that audience claim but that is just working around the
MUST in the spec. Given the lack of specificity of the 'aud' claim and
the 'resource indicator' claim for that matter, pretty much anything can
be made to comply. In that context, it seems like RECOMMEND is a better
normative clause.
For 1st party solutions, I would argue that delegation might not be the
right primitive hence I wouldn't necessarily use scopes to express permissions;
but that's a rabbit hole I'll try to avoid for the time being __
For the aud, I think that what you characterized as workaround would
actually be by design. The aud defines the applicability of the current token,
so that in case of leakage the blast radius of the incident can be contained.
If the solution designed decides that this particular token should be reusable
across multiple assets, I think it makes sense for the aud to reflect that
explicitly. That's the system designing volunteering a scope xpansion of the
scope, and given that it has security implications I think it's good to require
it to be an explicit, opt in action. At the same time, given that scopes are
often used to define permissions, I believe it makes sense to find mechanisms
to minimize the chance that RSes would misinterpret the applicability of a
scope (see discussion with Takahiko/Nikos). Summing all the above, I'd be
inclined to keep the MUST.
> Section 3. Requesting a JWT Access Token
�� Per my comments above I suspect that requiring all JWT access
tokens
to include an audience claim will just devolve to audience claims that
are somewhat pointless (in order to meet this MUST in the spec). Given
the mobile app environment today, it is unreasonable to ask the mobile
apps to downscope every access token before making an API call to the
backend APIs which is what the spirit of audience and resource
indicators seem to imply.
Partly addressed in the preceding point, but this is a great opportunity
to clarify the intent further. The mobile client isn't required to downscope;
rather, the fact that a token cab be applied to a broad range of API should be
clearly identified and expressed by the logical audience. The system designer
can even choose to have a single token that can be used to call any API,
containing every scope for every API; the profile only asks for this choice to
be manifest, by choosing an appropriate audience identifier and acknowledging
that all the scopes in the token are applicable to the same logical resource
(that is, the aggregate of all the APIs).
> �� Why MUST the AS reject a request with more than one resource
parameter? If a request comes in with no resource parameter and
multiple
scopes the AS is not required to reject that request. Is there much of
a
semantic difference between the two? In the case of no resource
parameter and multiple scopes the AS might issue an access token with
multiple audience values (as is allowed by RFC 7519).
This is another consequence of making extra clear what the token refers
to, and what the intended semantic of the scopes is. The idea is that the token
is always restricted to ONE specific audience. The profile allows for different
mechanisms for the AS to determine what value the audience should be, including
via inference from scopes, but coherently with the scope confusion prevention
principle, if that inference cannot lead to a single resource identifier in the
audience, the request should be rejected.
The intent is really to be as simple as unambiguous as possible, and
capture what most mainstream providers already do in JWT ATs. If a RS has more
sophisticated requirements, they can always decide to do more and not follow
the interop profile. Defining more complex rules to prevent scope/resource
association confusion simply doesn’t seem to be justified by the frequency of
the scenario in the wild.
> Also, the audience
claim is not solely for resource indicator values but is defined to
just
be a string. To me it feels like the text is implying that the only
valid audience value is also a resource indicator (which from previous
discussions on the list it was implied they have a slightly different
semantic).
Section 3 of the profile does define aud as a resource indicator,
enumerating an exhaustive list of possible requests that all end in a resource
indicator as aud, or an error. Did I miss some cases? I don’t recall specifics
about aud values in this profile having other possible values, sorry for having
missed that. Do you have a snippet referring to those discussions? Thx
> �� The model described here works well if myco.example really
only
provides a single service. But if instead myco.example provides
multiple
services each with their own endpoints (srva.myco.example,
srvb.myco.example) and scopes, for me this model begins to break down.
Either mobile apps are required to downscope all tokens to just the
service they are calling at that point in time (which can have latency
and connectivity issues), or myco.example has to create a generic
"audience" string that represents all of example.com which doesn't seem
to be the spirit of the existing specs.
I think that the granularity of the calls is fully within the control of
the designer. If srva.myco.example and srvb.myco.example share analogous
characteristics (same policies, lifecycle, resource ownership, etc) them it's
perfectly valid to assign a logical myco.example audience encompassing them
all, regardless of deployment model. If there are differences in terms of
policies, auth strength requirements, lifecycle, risk and impact of a leak, or
any other boundary, then the audience requirement will guarantee that those
differences are reflected in tokens requested and cached, in the way in which
access is partitioned, and so on and so forth. If there are security
requirements such as the ones enumerated, the latency and connectivity issues
aren’t a blocking factor; and if there aren't, nothing prevents you from having
a logical audience value. From the expressive power point of view, the
requirement of having a single audience doens't prevent you from doing any of
the single token logic you are hinting at- especially if you plan to use
specialized scopes anyway.
> �� In summary, I feel that this text is binding too tightly
resource
indicators to the audience claim. What is described is perfectly
reasonable in a use case that is applying resource indicators in this
way but is not indicative of the widely deployed models that already
exist.
We might have different experiences here. The JWT access tokens from
popular products I studied in the research I presented in Stuttgart were almost
all using the aud claim in this way. I am sure that there are other models, and
there was at least one exception, but in interop terms this seems to be the
most common way of using JWT for ATs- and it has the advantage of being very
simple and unambiguous.
> Section 4. Validating JWT Access Tokens
�� Step 4. -- Can we change the wording to not require resource
indicators? What about... "The resource server MUST validate that the
'aud' claim contains a string that represents the audience of this
resource server."
Could you make an example in which you'd want to use an identifier that is not a
resource indicator? Given that we have the spec, and "audience of the resource
server" seems to be the exact semantic of resource indicators, it seemed a slam dunk
to use it here...
> Section 5. "cross-JWT confusion"
�� I think there may be confusion around what is meant by
"distinct
resources". In my example above, are srva.myco.example and
srvb.myco.example "distinct resources"? or is the goal here to say that
we want different audience values generated for cross-organization
resources. For example, are mail.google.com and youtube.com "distinct
resources"? or would an audience for google suffice in meeting the
meaning of this paragraph?
I think the key point here is - we don’t know. I agree the language isn't
clear there. Let me expand on the intent, and perhaps we can get to a better
formulation.
OAuth2 doesn’t demand that RS and AS are run by the same entity, but
that's the most common scenario. FB doesn't need to specify a resource, because
the resource is implicit.. it's the FB graph, you can’t get a token for
anything else. The only differentiator ends up being the scopes. Same for many
other providers, google, Microsoft for its own Graph, etc.
However many AS as a service don’t have the benefit of a default, implicit resource,
especially in multi tenancy scenarios, given that they'll need to issue tokens for a
number of different recipients. Whether resources are cross organization, or cross
department, or following any other arbitrary segregation/factoring model is something we
cannot infer- it's up to the developer to determine that. What I am trying to express
here is that the operator of the AS as a service (or any other form of "AS for
rent") should surface resources as a primitive for modeling and identifying intended
recipients of ATs. Does tis help? How would you express that?
> � I'm having the same confusion in the next paragraph regarding
the
phrase "different resources". Are services provided by the same company
"different resources" or are they all considered the same resource. Can
an access token be issued with scopes for both mail.google.com and
youtube.com? And if not, why note? Preventing this puts undue burden on
mobile based applications.
See preceding point. We can't enter in the merit of what constitutes a
resource, as that depends on the modeling of the domain specific problem the
developer is tackling. The highest order bit is that if two entities (API,
etc.. intended token recipients) have different security characteristics (e.g.
leaking a token for one has different consequences than if you'd leak a token
for the other), they should be modeled as different resources. And if they are
different resources, we should do what we can to avoid confusion in how we
express access grants to them (hence the big discussion on multiresource, scope
confusion, etc).
---------
On 3/24/20, 10:39, "George Fletcher" <gffle...@aol.com> wrote:
Feedback on the spec...
Section 1. Introduction
��� second line: scenario should be plural --> scenarios
��� second sentence: "are not ran by" --> "are not run by"
Section 2.2.1 Authentication Information Claims
��� I'm not sure that this definition of `auth_time` allows for
the
case where a user is required to solve an additional challenge. Take
the
case of a user who is required to pass a secondary challenge before the
"stock purchase" action can be completed. According to the current spec
definition, the `auth_time` value MUST NOT be updated when this
secondary challenge is completed.
��� I think there is a difference between session_start_time
and last
auth_time. This feels more like it's defining the session_start_time
concept.
�� These same issues can apply to the `acr` and `amr` values as
well.
�� Even if for this secondary challenge a new refresh_token is
issued,
it is unlikely many relying parties will want to treat that as issuing
a
new session. The goal is to keep the user logged in to a single
session.
Section 2.2.3 Authorization Claims
�� I find the statement "All the individual scope strings in the
scope
claim MUST have meaning for the resource indicated in the aud claim"
somewhat problematic. In many deployments today for 1st party clients
to
the authorization server and taking into account mobile applications,
the access token most like contains scopes for many of the 1st party
backend APIs. It's possible to get around this by setting the 'aud'
claim to something like "com.example.apis" and hence all the issued
scopes map to that audience claim but that is just working around the
MUST in the spec. Given the lack of specificity of the 'aud' claim and
the 'resource indicator' claim for that matter, pretty much anything
can
be made to comply. In that context, it seems like RECOMMEND is a better
normative clause.
Section 3. Requesting a JWT Access Token
�� Per my comments above I suspect that requiring all JWT access
tokens
to include an audience claim will just devolve to audience claims that
are somewhat pointless (in order to meet this MUST in the spec). Given
the mobile app environment today, it is unreasonable to ask the mobile
apps to downscope every access token before making an API call to the
backend APIs which is what the spirit of audience and resource
indicators seem to imply.
�� Why MUST the AS reject a request with more than one resource
parameter? If a request comes in with no resource parameter and
multiple
scopes the AS is not required to reject that request. Is there much of
a
semantic difference between the two? In the case of no resource
parameter and multiple scopes the AS might issue an access token with
multiple audience values (as is allowed by RFC 7519). Also, the
audience
claim is not solely for resource indicator values but is defined to
just
be a string. To me it feels like the text is implying that the only
valid audience value is also a resource indicator (which from previous
discussions on the list it was implied they have a slightly different
semantic).
�� The model described here works well if myco.example really only
provides a single service. But if instead myco.example provides
multiple
services each with their own endpoints (srva.myco.example,
srvb.myco.example) and scopes, for me this model begins to break down.
Either mobile apps are required to downscope all tokens to just the
service they are calling at that point in time (which can have latency
and connectivity issues), or myco.example has to create a generic
"audience" string that represents all of example.com which doesn't seem
to be the spirit of the existing specs.
�� In summary, I feel that this text is binding too tightly
resource
indicators to the audience claim. What is described is perfectly
reasonable in a use case that is applying resource indicators in this
way but is not indicative of the widely deployed models that already
exist.
Section 4. Validating JWT Access Tokens
�� Step 4. -- Can we change the wording to not require resource
indicators? What about... "The resource server MUST validate that the
'aud' claim contains a string that represents the audience of this
resource server."
Section 5. "cross-JWT confusion"
�� I think there may be confusion around what is meant by
"distinct
resources". In my example above, are srva.myco.example and
srvb.myco.example "distinct resources"? or is the goal here to say that
we want different audience values generated for cross-organization
resources. For example, are mail.google.com and youtube.com "distinct
resources"? or would an audience for google suffice in meeting the
meaning of this paragraph?
� I'm having the same confusion in the next paragraph regarding the
phrase "different resources". Are services provided by the same company
"different resources" or are they all considered the same resource. Can
an access token be issued with scopes for both mail.google.com and
youtube.com? And if not, why note? Preventing this puts undue burden on
mobile based applications.
Section 6. Privacy
�� cofidentiality --> confidentiality
Thanks,
George
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
