Hi Johan,

thanks for your proposal. I’m not sure whether it should go to 3.7.1.4. The 
reason audience restriction turns up as a subsection of 3.7 is our document is 
organized by attacks instead of security controls. I could image to add a 
section on audience/action restriction as sub section of 2.

What is the mean reason for restricting access tokens to certain actions? Is it 
about least privileges? Is it to limit the impact of a token leakage/replay? ...

best regards,
Torsten.  

> Am 07.04.2018 um 19:11 schrieb Johan Peeters <y...@johanpeeters.com>:
> 
> Thanks for doing this great work, Torsten. As discussed in a private
> email conversation, I think an access token should not only be
> explicit about which resource server is the intended consumer
> (audience), but also which actions are permitted on the targeted
> resources:
> 
> =========3.7.1.4. Action Restricted Access Tokens=========
> 
>   An action restriction restricts the action a
>   particular access token can be used for.  The authorization server
>   associates the access token with a certain action and every
>   resource server is obliged to verify for every request, whether the
>   access token sent with that request was meant to be used for that
>   particular action.  If not, the resource server must refuse
>   to serve the respective request.  Action
>   restrictions limit the impact of a token leakage and prevent a
> malicious client to use the token for unintended actions.
> 
>   The action attribute in  can be expressed as the HTTP verb used to
> make the request.
> 
>   The client needs to tell the authorization server, for which actions it
>   will use the access token it is requesting.  It should encode
>   the information in the scope value.
> 
>   Action restrictions are essential both to enforce scope
> restrictions as established through user dialog and policy decisions
> by the authorization server.
> 
> ==========================
> 
> Yo
> -- 
> Johan Peeters
> https://www.johanpeeters.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to