What does "up-scoping is not allowed" mean?

[XMol]

Hi @zachmann,

I've set up a mytoken client on my machine with a token issued by mytoken.data.kit.edu and "wlcg" (wlcg.cloud.cnaf.infn.it) as provider[1]. But when I try to get an access token with it, only the error "Up-scoping is not allowed" is returned.

I don't understand the error. The (dynamically registered) client at wlcg.cloud.cnaf.infn.it allows way broader scope than I wanted the MT to use (seems like the mytoken server UI doesn't put that as a restriction into the database). But even limiting the scope on command line yields the same error.

$ jwt_decode <.mytoken/mytoken.data.kit.edu/wlcg.cnaf.mt
{
  "ver": "0.6",
  "token_type": "mytoken",
  "iss": "https://mytoken.data.kit.edu/",
  "sub": "...",
  "seq_no": 1,
  "name": "gridka-monitoring",
  "aud": "https://mytoken.data.kit.edu/",
  "oidc_sub": "...",
  "oidc_iss": "https://wlcg.cloud.cnaf.infn.it/",
  "capabilities": [
    "AT",
    "tokeninfo"
  ],
  "nbf": 1706085638,
  "iat": 1706085638,
  "auth_time": 1706085638,
  "jti": "..."
}

$ mytoken at --MT-file .mytoken/mytoken.data.kit.edu/wlcg.cnaf.mt
oidc_error: invalid_scope: Up-scoping is not allowed.
$ mytoken at --MT-file .mytoken/mytoken.data.kit.edu/wlcg.cnaf.mt --scope storage.read:/
oidc_error: invalid_scope: Up-scoping is not allowed.

mytoken has no verbose or debug mode, so I'm uncertain which party raised this error.

[XMol]

Now I've created a new MT with scope restrictions included and mytoken is able to obtain ATs just fine.

$ jwt_decode <.mytoken/mytoken.data.kit.edu/wlcg.cnaf.mt
{
  "ver": "0.6",
  "token_type": "mytoken",
  "iss": "https://mytoken.data.kit.edu/",
  "sub": "szq/Z2I1Q7cip2oh3YxZg514QXEnnWNxsxRkWBY0uL0=",
  "seq_no": 1,
  "name": "gridka-monitoring-restricted",
  "aud": "https://mytoken.data.kit.edu/",
  "oidc_sub": "d00e6f11-f45a-465d-975b-0b5083c44b7f",
  "oidc_iss": "https://wlcg.cloud.cnaf.infn.it/",
  "capabilities": [
    "AT",
    "tokeninfo"
  ],
  "nbf": 1706092825,
  "iat": 1706092825,
  "auth_time": 1706092825,
  "jti": "dcc4d5e4-3948-4961-9824-b489903d2646",
  "restrictions": [
    {
      "scope": "storage.create:/ storage.read:/ storage.modify:/ storage.stage:/ wlcg wlcg.groups",
      "audience": [
        "https://wlcg.cern.ch/jwt/v1/any"
      ]
    }
  ]
}

$ mytoken at --MT-file .mytoken/mytoken.data.kit.edu/wlcg.cnaf.mt | jwt_decode
{
  "wlcg.ver": "1.0",
  "sub": "...",
  "aud": "https://wlcg.cern.ch/jwt/v1/any",
  "nbf": 1706107287,
  "scope": "storage.create:/ storage.read:/ storage.stage:/ storage.modify:/ wlcg wlcg.groups",
  "iss": "https://wlcg.cloud.cnaf.infn.it/",
  "exp": 1706110887,
  "iat": 1706107287,
  "jti": "...",
  "client_id": "...",
  "wlcg.groups": [
    "/wlcg",
    "/wlcg/xfers"
  ]
}

I simply did not understand that the GUI for creating MTs on mytoken.data.kit.edu changes the restrictions immediately, in-place. Therefor my previous MT was completely unrestricted. My guess is, that in this configuration mytoken.data.kit.edu uses some syntax that wlcg.cloud.cnaf.infn.it understands as requesting more scopes then the client was originally registered for.

[zachmann]

If no scopes restrictions are given, the mytoken has alle the scopes available that are registered for the client that is used with the mytoken server instance. This should not be a problem. I tried the following:

• Created a mytoken on the webinterface (has some default restrictions) or in the cmd line client (no restrictions)
• Used it to obtain an AT: mytoken at

This did work fine for me.

[XMol]

Did your AT then have any storage scope claim?

[XMol]

Sorry, I linked your comment to the wrong issue in my head. Do you want me to reproduce the issue? I had closed it already as user-error.

[zachmann]

Yes:

{
  "wlcg.ver": "1.0",
  "sub": "50a4837f-f34c-4819-bef7-17fbea86f375",
  "aud": "https://wlcg.cern.ch/jwt/v1/any",
  "nbf": 1706542432,
  "scope": "entitlements openid compute.create profile compute.read storage.read:/ compute.modify storage.stage:/ eduperson_entitlement wlcg storage.create:/ compute.cancel eduperson_scoped_affiliation eduperson_assurance storage.modify:/ email wlcg.groups",
  "iss": "https://wlcg.cloud.cnaf.infn.it/",
  "exp": 1706546032,
  "iat": 1706542432,
  "jti": "8c77f4bc-ff82-4541-8b49-4209f041e145",
  "client_id": "221734cc-257d-4b56-9869-4f32cde240cd",
  "wlcg.groups": [
    "/wlcg",
    "/wlcg/pilots",
    "/wlcg/xfers"
  ]
}

[zachmann]

Sorry, I linked your comment to the wrong issue in my head. Do you want me to reproduce the issue? I had closed it already as user-error.

If you can reproduce the issue, that might be something we should fix. Because if I understood correctly, what you described should work.

[zachmann]

However, what might be the problem is that we try to obtain all the scopes configured for our client which includes storage scopes as well as compute scopes. But those scopes are only available to users within a certain group. You are in the /wlcg/xfers group but not in /wlcg/pilots. So that might be the problem.

[XMol]

reproduce the issue by using an MT token without any restrictions

$ jwt_decode <.mytoken/wlcg-scope-issue-unrestricted.mt
{
  "ver": "0.6",
  "token_type": "mytoken",
  "iss": "https://mytoken.data.kit.edu/",
  "sub": "...",
  "seq_no": 1,
  "name": "demo-scope-issue",
  "aud": "https://mytoken.data.kit.edu/",
  "oidc_sub": "...",
  "oidc_iss": "https://wlcg.cloud.cnaf.infn.it/",
  "capabilities": [
    "AT",
    "tokeninfo"
  ],
  "nbf": 1706543601,
  "iat": 1706543601,
  "auth_time": 1706543601,
  "jti": "..."
}
$ mytoken AT --MT-file .mytoken/wlcg-scope-issue-unrestricted.mt | jwt_decode
oidc_error: invalid_scope: Up-scoping is not allowed.

[zachmann]

I can use a mytoken without restrictions successfully. As I said, I guess it is related to the groups. I'll look into the code so see if we can improve there.