[openid-specs-rande] AUD Claim

[Torsten Lodderstedt]

Hi Hannah,

> On 25. Feb 2020, at 11:48, Hannah Short <hannah.short08 at gmail.com> wrote:
> 
> 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.

The spec intentionally recommends restriction to a particular resource server to limit the privileges associated with it. This is especially important if you intend to use audience restriction "to mitigate the impact of stolen Access Token”. The more resource servers you add to the audience, the less effective is this measure for replay prevention. 

Beside this, as I pointed out, audience restriction is not the recommended way "to mitigate the impact of stolen Access Token”. I would recommend you to utilise sender constraint access tokens using mTLS for OAuth for that purpose. It’s easy to handle and mature. 

best regards,
Torsten. 

> 
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20200225/3a1f4d91/attachment.p7s>