Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

["Richard Backman, Annabelle" <[e-mail]>]

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" <[e-mail] on behalf of vittorio.bertocci=[e-mail]> 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" <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth