[openid-specs-rande] AUD Claim

[Torsten Lodderstedt]

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