OAuth 2.0 with complex or fine-grained scopes

Question

I am currently working on an OAuth2 implementation for all the clients (web and mobile). So far nothing fancy about it, but we want to have more complexity in the scope, so that we can grant partial access to certain objects down to the granularity of a single property.

Example: Client gets access for a resource, let's say a user object with all its common properties. The client has full read access, but is only allowed to edit certain properties, e.g. password and username, but not location and/or birthday.

So far my thoughts are, that this granularity is defined at the Authorization Server and just interpreted by the Resource Server.

Based on the RFC the scope is a string based comma separated value, so a plain list (https://www.rfc-editor.org/rfc/rfc6749#page-23)

The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings. The strings are defined by the
authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an
additional access range to the requested scope.

 scope       = scope-token *( SP scope-token )
 scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

So my first assumption providing json as the scope may not work, so I thought about introducing namespaces which might get to complex, e.g. (scope: user-write-full-read-list of properties or something similar).

Is there any best practice, am I missing something in the RFC or am I abusing OAuth completely?

Answer 1

You may want to consider the UMA protocol. The UMA RPT token is presented by the client to the Resource Server. The RPT token is issued by the Authorization Server (AS) with certain scopes. On the AS, scopes map to policies, such as who can get to what API's using which clients, network, required crypto, time of day, etc. These policies may be expressed in code or a more structured policy syntax like XACML, such as David suggested above.

If you want to learn more about UMA, I would start with this diagram:

In this case, there are two OAuth2 clients: the Resource Server (the thing with the APIs) and the Requesting Party (either a mobile application or web site). The PAT and the AAT are normally OpenID Connect client tokens. The UMA Core spec says "OAuth2", but the only profile of OAuth2 for crypto client registration is OpenID Connect, so its implicit.

The Resource Owner is the one who makes the policies. These policies can be algorithmic or may require action by the Resource Owner. For more information about OpenID Connect, see

OpenID Connect Website

For more information about UMA see:

UMA Website

If you are looking for a free open source OAuth2 authorization server, you should take a look at the Gluu Server, which is an OpenID Connect Provider and an UMA Authorization Server for FOSS Access Management