Question

Specifying an API for library patrons, compatible with OAuth2.0, I stumbled across OAuth scopes. The OAuth2.0 specification seems to be interpreted differently at some points, for instance GitHub uses commas to delimit scopes while Google uses spaces, as defined in RFC 6749. The RFCs tells:

If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted

But no scope response parameter is mentioned later in the specification. In particular I want to implement Resource Owner Password Credentials Grant (section 4.3.). This example of a response is given in the OAuth2.0 specification:

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "example_parameter":"example_value"
 }

Should I include the scopes as space-separated list, as comma-separated list or as JSON arary?

 {
   "scope": [ "read", "write", "foobar" ],
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "example_parameter":"example_value"
 }

Answer 1

My interpretation of RFC 6749 is that the scopes should be specified as a string containing a space-separated list. The standard is somewhat open to interpretation because of the lack of an example.

"scope": "read write foobar"

RFC 6749 Section 4.3.3 Access Token Response says:

If the access token request is valid and authorized, the authorization
server issues an access token and optional refresh token as described
in Section 5.1.

RFC 6749 Section 5.1 says:

scope
OPTIONAL, if identical to the scope requested by the client;
otherwise, REQUIRED. The scope of the access token as
described by Section 3.3.

RFC 6749 Section 3.3 says:

scope = scope-token *( SP scope-token )