Password Grant: requesting specific scopes causes response to have no scopes

General
,
#1

I’m making the following request:

{{baseUrl}}/oauth/token
{
  "grant_type": "http://auth0.com/oauth/grant-type/password-realm",
  "realm": "{{realm}}",
  "username": "{{username}}",
  "password": "{{password}}",
  "audience": "{{apiIdentifier}}",
  "scope": "",
  "client_id": "{{clientId}}"
}

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.

#2

@bugged what API are you trying to get scopes for? Is it a custom API or Auth0’s Management API?

#3

If I specify “openid” as the only scope in the request, then I get back not only “openid profile email address phone customScope1 customScope2”

If I specify “openid email” in the request, then I get back only “openid email customScope1 customScope2”

If I specify “openid email customScope1” then I get back a response with no scope field again.

I’m not sure I understand the inconsistency of this flow…

#4

It’s a custom API that I’ve configured with two sample scopes for testing.

#5

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.

#6

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).

#7

@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.

Out of curiosity do you have any rules or hooks?

#8

So far I haven’t been able to reproduce this issue. Here is a sample cURL I used for password type:

curl -X POST \
  https://your-tenant.auth0.com/oauth/token \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=password&client_id=nk3BTvaqiE86eUTd6Ti5bFoCPri5kxkM&audience=https%3A%2F%2Fexample.com/api/%2F&username=username&password=top-secre-password&scope=openid%20read%3Alist&client_secret=client-top-secret-pwd'

With the resulting decoded payload:

"iss": "https://your-tenant.auth0.com/",
  "sub": "auth0|random-user-id",
  "aud": [
    "https://example.com/api/",
    "https://your-tenant.auth0.com/userinfo"
  ],
  "iat": 1527275529,
  "exp": 1527361929,
  "azp": "your-client-id",
  "scope": "openid profile email address phone read:list update:list",
  "gty": "password"

And now for password realm cURL:

curl -X POST \
  https://your-tenant.auth0.com/oauth/token \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=http%3A%2F%2Fauth0.com%2Foauth%2Fgrant-type%2Fpassword-realm&client_id=your-client-id&audience=https%3A%2F%2Fexample.com%2Fapi%2F&username=user%40example.com&password=top-secret-pwd&scope=openid%20read%3Alist&client_secret=redacted&realm=Database-Name'

And here are those results:

{
  "iss": "https://your-tenant.auth0.com/",
  "sub": "auth0|random-user-id",
  "aud": [
    "https://example.com/api/",
    "https://your-tenant.auth0.com/userinfo"
  ],
  "iat": 1527276412,
  "exp": 1527362812,
  "azp": "your-client-id",
  "scope": "openid profile email address phone read:list",
  "gty": "password"
}

In both situations I was not able to reproduce your results.

#9

No rules or hooks are configured for my tenant.

#10

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.

#11

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?

#12

The cases I described above were all cases where the scope property of the response did NOT match the scope claim of the returned access token.

#13

Ok I will keep trying to reproduce however I’ve not seen that happen. Can you DM me your tenant info?

#14