<div dir="ltr">Thanks for raising this, Marcus!<div><br></div><div>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.</div><div><br></div><div>Cheers,<br>Hannah</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 Feb 2020 at 18:01, Torsten Lodderstedt via openid-specs-rande <<a href="mailto:openid-specs-rande@lists.openid.net" target="_blank">openid-specs-rande@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
the OAuth Security BCP (<a href="https://tools.ietf.org/html/draft-ietf-oauth-security-topics" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-ietf-oauth-security-topics</a>) 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.  <br>
<br>
Audience & privilege restriction are generally a very good security practice, but they especially do not prevent replay with the same resource server.  <br>
<br>
best regards,<br>
Torsten. <br>
<br>
> On 21. Feb 2020, at 17:20, Marcus Hardt <<a href="mailto:hardt@kit.edu" target="_blank">hardt@kit.edu</a>> wrote:<br>
> <br>
> Hello Everyone,<br>
> <br>
> at the TIIME Unconference we discussed the usage of the optional aud claim<br>
> in JWT Access Tokens.<br>
> <br>
> AUD is one of the registered claims in rfc7519.<br>
> <br>
> The discussion came up, because we noticed that several communities (we<br>
> spontaneously came up with ESA, WLCG, FNAL, CERN, UK-IRIS, DAASI?, Life<br>
> Science AAI) want to use Access Tokens as Bearer Tokens.  People were<br>
> looking at the aud claim, to mitigate the impact of stolen Access Token.<br>
> <br>
> We felt it was sensible to have (at least) a discussion about a structure<br>
> for the aud claim, because the spec is not very specific. It merely<br>
> suggests using an array containing a StringOrURI values.<br>
> <br>
> Examples we found for the aud claim included:<br>
> - Compute<br>
> - Storage<br>
> - <Infrastructure-Name or URN><br>
> - <Infrastructure-Name or URN>:Compute<br>
> <br>
> Delegation was another use case. I.e. a compute resource may need to give<br>
> another component access to storage. This lead to discussing the behaviour<br>
> of token exchange (rfc8693) and how it relates to the aud claim. One idea<br>
> was to describe the way in which aud claims may be narrowed down but not<br>
> extended.<br>
> <br>
> Also, we discussed the relation to the optional scope claim.<br>
> <br>
> <br>
> To keep different infrastructures from coming up with separate approaches,<br>
> the plan would be to consider describing/defining this further. Either in<br>
> an recommendation or even in an rfc.<br>
> <br>
> Can we put this on the agenda of an OIDC-RANDE call? (Possibly ending the<br>
> discussion well before 16:30, if it's a monday).<br>
> <br>
> [rfc7915] <a href="https://tools.ietf.org/html/rfc7915" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc7915</a> (JWT)<br>
> [rfc8693] <a href="https://tools.ietf.org/html/rfc8693" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc8693</a> (Token Exchange)<br>
> <br>
> Cheers,<br>
> -- <br>
> Marcus.<br>
> -- <br>
> openid-specs-rande mailing list<br>
> <a href="mailto:openid-specs-rande@lists.openid.net" target="_blank">openid-specs-rande@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-rande" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-rande</a><br>
<br>
-- <br>
openid-specs-rande mailing list<br>
<a href="mailto:openid-specs-rande@lists.openid.net" target="_blank">openid-specs-rande@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-rande" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-rande</a><br>
</blockquote></div>