From Properties to Capabilities

Hal Lockhart has an interesting post on different authorization models, distinguished by the nature of the claims/attributes made within some token/assertion. Hal argues that there is a spectrum between 'properties' (where the attributescontain information about who/what the Subject is) and 'capabilities' (where the attributes contain information about what the Subject is allowed to do).

Coincidentally, I was working at my 'drawings' this morning - sketching out something similar for OAuth.

The diagram below shows three different models for the interaction between OAuth Client, Authorization Server, and Resource Server.

In the top model, the Client requests of the OAuth AS a token, but does not specify any particular RS target. Consequently, the AS can issue a token with claims that contain only generic attributes of the Client/Subject.  This is Hal's properties model. The AS authenticates, the RS authorizes.

In the bottom model, the Client includes in its request to the AS the scope of what actions it desires to perform at the RS. The token that the AS subsequently issues reflects a positive authorization decision and not some generic attribute of the Client. This is Hal's capabilities model. The AS makes an authorization decision and tells the RS about it. Makes for simple RSs.

Reflecting the delegated authorization use case that originally motivated OAuth - it is the capabilities model that gets the most attention. The assumption is that the OAuth access token issued to the Client reflects a set of capabilities assigned to it by the Resource Owner. But there are lots of applications of OAuth where the access token wont reflect capabilities but simply Client properties.

Note: The middle model  has the respponsibility for the complete authorization decision shared amongst the AS & RS. It is there because any good taxonomy has at least 3 permutations - I have nothing more to say about it.