[openid-specs-rande] AUD Claim

[Hannah Short]

Thanks for raising this, Marcus!

Ideally we can strike a balance between token reusability (limiting the
need to exchange tokens) and segregation into logical audiences to help
mitigate risk. Thanks for the spec, Torsten, I took a look and saw "In
particular, access tokens SHOULD be restricted to certain resource servers
(audience restriction), preferably to a single resource server." In our
case we are going to need to have sets of resource servers (e.g. Computing
and Storage as Marcus mentioned). I imagine this is still within the spirit
of the doc.

Cheers,
Hannah

On Fri, 21 Feb 2020 at 18:01, Torsten Lodderstedt via openid-specs-rande <
openid-specs-rande at lists.openid.net> wrote:

> Hi,
>
> the OAuth Security BCP (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics) gives
> advice on access token replay prevention (Section 2.2), it recommends
> sender constrained access tokens. It also has a discussion of different
> countermeasures in Section 4.8, which includes the audience restriction
> that you seem to prefer.
>
> Audience & privilege restriction are generally a very good security
> practice, but they especially do not prevent replay with the same resource
> server.
>
> best regards,
> Torsten.
>
> > On 21. Feb 2020, at 17:20, Marcus Hardt <hardt at kit.edu> wrote:
> >
> > Hello Everyone,
> >
> > at the TIIME Unconference we discussed the usage of the optional aud
> claim
> > in JWT Access Tokens.
> >
> > AUD is one of the registered claims in rfc7519.
> >
> > The discussion came up, because we noticed that several communities (we
> > spontaneously came up with ESA, WLCG, FNAL, CERN, UK-IRIS, DAASI?, Life
> > Science AAI) want to use Access Tokens as Bearer Tokens.  People were
> > looking at the aud claim, to mitigate the impact of stolen Access Token.
> >
> > We felt it was sensible to have (at least) a discussion about a structure
> > for the aud claim, because the spec is not very specific. It merely
> > suggests using an array containing a StringOrURI values.
> >
> > Examples we found for the aud claim included:
> > - Compute
> > - Storage
> > - <Infrastructure-Name or URN>
> > - <Infrastructure-Name or URN>:Compute
> >
> > Delegation was another use case. I.e. a compute resource may need to give
> > another component access to storage. This lead to discussing the
> behaviour
> > of token exchange (rfc8693) and how it relates to the aud claim. One idea
> > was to describe the way in which aud claims may be narrowed down but not
> > extended.
> >
> > Also, we discussed the relation to the optional scope claim.
> >
> >
> > To keep different infrastructures from coming up with separate
> approaches,
> > the plan would be to consider describing/defining this further. Either in
> > an recommendation or even in an rfc.
> >
> > Can we put this on the agenda of an OIDC-RANDE call? (Possibly ending the
> > discussion well before 16:30, if it's a monday).
> >
> > [rfc7915] https://tools.ietf.org/html/rfc7915 (JWT)
> > [rfc8693] https://tools.ietf.org/html/rfc8693 (Token Exchange)
> >
> > Cheers,
> > --
> > Marcus.
> > --
> > openid-specs-rande mailing list
> > openid-specs-rande at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-rande
>
> --
> openid-specs-rande mailing list
> openid-specs-rande at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-rande
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20200225/775c9177/attachment.html>