Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Dominick Baier <[e-mail]>]

My experience:

When building modern applications, we use OIDC and OAuth together for
authentication, session management and API access. Only the combination
makes sense (to me) here. Hence it also makes sense (for me) to share
claims types going forward.

IdentityServer is a framework that is typically used when building new
applications (or modernising them) so we have the luxury of a lot of
“Greenfield-ish” scenarios - I acknowledge that this might not apply to
everyone on this list.

Maybe we need a “base profile” + “end-user identity” extensions...

———
Dominick

On 3. April 2019 at 21:38:55, Vittorio Bertocci (
vittorio=[e-mail]) wrote:

Thanks guys for the comment, sorry for the delay in addressing them.
I am not married to the claim types used in here, so if you think that
reusing the ones in the id_token can cause confusion we should expand on
the specific ways in which you think might go south.
However I think it's important that the information on say, whether the
current token was obtained using MFA or a specific authentication factor is
something that API developers can legitimately latch to when doing
authorization decisions. From the perspective of a developer modeling a
solution, whether functionality is delivered as a route in a postback based
web app (hence receiving an id_token or derived) or as an API consumed by a
native app, the business requirement gating access to that functionality
doesn't change. If the admin managing that resource establishes that access
should be performed only via MFA, the developer should be equipped to
enforce that regardless of the stack used to expose functionality (web app,
API).
Although it is true that triggering the desired behavior might be achieved
by the resource setting and contract with the AS, along the lines of what
David said, it's actually not uncommon for those policies to be assigned on
the resource AFTER the current session was established and/or the
corresponding AT was obtained and cached. Furthermore, the requirement
might be more granular than an AS policy can tolerate (an API might
requires MFA only for certain routes, hence hard to express in a static
policy) and triggered in form of challenges. So the situation in which you
have an AT with the right issuer, audience, etc but was obtained with a
policy now obsolete/unacceptable to the RP is strong. Requesting to support
revocation just for this seems overkill, especially given that the scenario
in which the same logical app is exposed as both web app and native
client+API, the code consuming those claims is already in place. It just
makes intuitive sense for developers.
In summary, one can take steps to push as much of the MFA requirements to
the AS settings for a particular request, but ultimately the desire of the
API developer to enforce that it actually happened is a requirement I
encountered often in practice. Anything providing extra context to refine
decisions about it (like auth_time, which might inform decisions about
whether to accept an MFA check occurred N minutes ago or refuse access).

I thought that reusing the existing names for the same concepts just made
sense (dev existing skills, existing codebases, etc etc) and especially in
the case in which the values are exactly the same, and the idea seemed to
receive good support during OSW. But I am completely open to change it of
course, especially for cases like the one identified by George.
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=
[e-mail]> wrote:

> +1 to David's question here. I'd like to see justifying use cases (beyond
> just the fact that some people are already doing it) for auth_time, acr,
> and amr to be available in OAuth JWT access tokens. Those claims are
> defined for, and in the context of, an ID Token and I fear that codifying
> their use in an access token will lead to misuse and/or confusion.
>
> On Mon, Apr 1, 2019 at 1:03 PM David Waite <[e-mail]>
> wrote:
>
>> Do we know if there is a justifying use case for auth_time, acr, and amr
>> to be available in OAuth JWT access tokens? These are meant to be messages
>> about the client, either directly (in the case of client credentials) or
>> about its delegated authorization of the user.
>>
>> Embedding attributes about the user (such as group membership and roles)
>> can be used for the resource to make finer-grained decisions than scopes,
>> but normally I would expect say acr limitations enforced by a resource to
>> instead be controlled by the AS requiring a higher quality authentication
>> to release certain scopes.
>>
>> Thats of course not to say extensions to OAuth such as OIDC can’t provide
>> these values, just that they might better be defined by those extensions.
>>
>> -DW
>>
>> On Apr 1, 2019, at 9:12 AM, George Fletcher <
>> gffletch=[e-mail]> wrote:
>>
>> Thanks for writing this up. One comment on auth_time...
>>
>> auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>>       Important: as this claim represents the time at which the end user
>>       authenticated, its value will remain the same for all the JWT
>>       access tokens issued within that session.  For example: all the
>>       JWT access tokens obtained with a given refresh token will all
>>       have the same value of auth_time, corresponding to the instant in
>>       which the user first authenticated to obtain the refresh token.
>>
>>
>> During a current session a user can be challenged for additional
>> credentials or required to re-authenticate due to a number of different
>> reasons. For example, OIDC prompt=login or max_age=NNN. In this context,
>> I'd assume that the auth_time value should be updated to the latest time at
>> which the user authenticated.
>>
>> If we need a timestamp for when the "session" started, then there could
>> be a session_start_time claim.
>>
>> Thanks,
>> George
>>
>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>
>> Dear all,
>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>> tokens. You can find it in
>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>> remotely). I look forward for your comments!
>>
>> Here's just a bit of backstory, in case you are interested in how this
>> doc came to be. The trajectory it followed is somewhat unusual.
>>
>>    - Despite OAuth2 not requiring any specific format for ATs, through
>>    the years I have come across multiple proprietary solution using JWT for
>>    their access token. The intent and scenarios addressed by those solutions
>>    are mostly the same across vendors, but the syntax and interpretations in
>>    the implementations are different enough to prevent developers from reusing
>>    code and skills when moving from product to product.
>>    - I asked several individuals from key products and services to share
>>    with me concrete examples of their JWT access tokens (THANK YOU Dominick
>>    Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>    Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!
>>    ).
>>    I studied and compared all those instances, identifying commonalities
>>    and differences.
>>    - I put together a presentation summarizing my findings and
>>    suggesting a rough interoperable profile (slides:
>>    https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>>    <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>    ) - got early feedback from Filip Skokan on it. Thx Filip!
>>    - The presentation was followed up by 1.5 hours of unconference
>>    discussion, which was incredibly valuable to get tight-loop feedback and
>>    incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>>    and contributed generously to the discussion. Thank you!!!
>>    Note: if you were at OSW2019, participated in the discussion and
>>    didn't get credited in the draft, my apologies: please send me a note and
>>    I'll make things right at the next update.
>>    - On my flight back I did my best to incorporate all the ideas and
>>    feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
>>    Hannes and above all Brian were all super helpful in negotiating the
>>    mysterious syntax of the RFC format and submission process.
>>
>> I was blown away by the availability, involvement and willingness to
>> invest time to get things right that everyone demonstrated in the process.
>> This is an amazing community.
>> V.
>>
>> _______________________________________________
>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> * CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited...  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any file
> attachments from your computer. Thank you.*
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth