Note that the value of the scope field is empty, in which case the response includes all scopes configured for my API. However, if I make the value of the scope field a specific scope, then the response is completely missing the entire scope field.
The docs here indicate that what I’m trying to do should work. I have no rules running in this scenario.
Password grant and standard scopes
If no API scopes (such as read:notes) are included in the request, all API scopes (such as read:notes, create:notes, and so on.) are included in the access_token. If only the openid scope is included in the request, all openid standard scopes will be returned, such as openid profile email address phone. In these cases, the scope parameter will be included in the response, listing the issued scopes. This happens because a password is equal to full access and hence any password-based exchange gives access to all scopes.
Admittedly that is weird. Have you happen to test this with other flows to seem similar behavior to what you see with Password Realm? I can do some testing on my end to see what happens with Password Realm. and see if I can reproduce it.
The behavior is also weird for the client_credentials grant.
I’ve configure my custom API to grant my machine-to-machine client 1 of 2 total scopes. Then if I request a token using the client_credentials grant with that client:
If I specify no scopes in the request, the response includes the 1 granted scope.
If I specify the non-granted scope in the request, then the expected 403 is returned.
If I specify the granted scope in the request, the response has no scope field at all (no scopes returned).
@bugged I can look into this as well. All the points you made in this last message seem congruent with what I’d expect. The odd thing here is when you request a scope you are authorized for you do not get anything returned.
I see the confusion. You are referring to the decoded contents of the access token. I’m referring to the response object returned by the /oauth/token endpoint. This object contains the access token field and (inconsistently) a scope field, among other things.
When an access token is returned you get a token response. In all cases the scope property of the token response matches the scope claim in contents of the payload. When you tested did you see these as being different?