oauth2: Custom claims param in /oauth2/auth is ignored

[wojciechce]

Do you want to request a feature or report a bug? Feature

What is the current behavior? Hydra doesn't handle custom claims param in /oauth2/auth request. All additional custom claims are present in ID Token by default. Claims param is ignored.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Regarding to specification I distinguished 3 cases: customClaimOfCase1: present in auth request and consent - should be present in ID Token customClaimOfCase2: present in auth request but not in consent - shouldn't be present in ID Token customClaimOfCase3: present in consent request but not in auth - shouldn't be present in ID Token

Steps to reproduce:

1. Follow the 5 minute tutorial, setup hydra.
2. Add auth-code-client client:

docker exec -it hydra_hydra_1 \
 hydra clients create \
 --endpoint http://localhost:4445 \
 --id auth-code-client \
 --secret secret \
 --grant-types authorization_code,refresh_token \
 --response-types code,id_token \
 --scope openid,offline \
 --callbacks http://127.0.0.1:5555/callback

3. Setup home route:

docker exec -it hydra_hydra_1 \
 hydra token user \
 --client-id auth-code-client \
 --client-secret secret \
 --endpoint http://localhost:4444/ \
 --port 5555 \
 --scope openid,offline

4. Open http://127.0.0.1:5555/ in your browser.
5. Copy url of Authorize application link.
6. Send GET request based on previous url, remember to add custom claims param on the end of url: &claims=%7B%22id_token%22%3A%20%7B%22customClaimOfCase1%22%3A%20null%2C%20%22customClaimOfCase2%22%3A%20null%7D%7D so it should look like below: http://localhost:4444/oauth2/auth?client_id=auth-code-client&redirect_uri=http%3A%2F%2F127.0.0.1%3A5555%2Fcallback&response_type=code&scope=openid+offline&state=rwscisrcsauiriwepgsfswmo&nonce=ggxjvxgidejnstqsfsvpfogz&prompt=&max_age=0&claims=%7B%22id_token%22%3A%20%7B%22customClaimOfCase1%22%3A%20null%2C%20%22customClaimOfCase2%22%3A%20null%7D%7D
7. Copy challenge value from response and perform new PUT request: http://localhost:4445/oauth2/auth/requests/login/{{challenge}}/accept that contains:

{
    "acr": "0",
    "remember": false,
    "remember_for": 0,
    "subject": "[email protected]",
    "force_subject_identifier": "[email protected]"
}

8. Enter the url that you got as response.
9. Copy new challenge from response and prepare new PUT request: http://localhost:4445/oauth2/auth/requests/consent/{{challenge}}/accept that contains:

{
    "grant_scope": ["login","offline","openid"],
    "remember": false,
    "remember_for": 0,
    "session": {
        "access_token": {
            "euid": "123",
            "jti": "69219f38-af68-11e8-96f8-529269fb1459"
        },
        "id_token": {
            "customClaimOfCase1": "shouldBeReturned",
            "customClaimOfCase3": "shouldntBeReturned"
        }
    }
}

10. Enter the redirect_to URL that you got in response, you should recieve encoded ID Token. After decoding it on https://jwt.io/ you will get something like:

{
    "aud": [
        "auth-code-client"
    ],
    "auth_time": 1535977708,
    "customClaimOfCase1": "shouldBeReturned",
    "customClaimOfCase3": "shouldntBeReturned",
    "exp": 1535981342,
    "iat": 1535977742,
    "iss": "http://localhost:4444/",
    "jti": "b8fe8754-4017-4a6d-a788-c92d358156ae",
    "nonce": "ggxjvxgidejnstqsfsvpfogz",
    "rat": 1535977681,
    "sub": "[email protected]"
}

Expected result:

{
    "aud": [
        "auth-code-client"
    ],
    "auth_time": 1535977708,
    "customClaimOfCase1": "shouldBeReturned",
    "exp": 1535981342,
    "iat": 1535977742,
    "iss": "http://localhost:4444/",
    "jti": "b8fe8754-4017-4a6d-a788-c92d358156ae",
    "nonce": "ggxjvxgidejnstqsfsvpfogz",
    "rat": 1535977681,
    "sub": "[email protected]"
}

What is the expected behavior? Hydra should handle claims param in /oauth2/auth request and then create ID Token that contains custom claims only those that were requested.

Which version of the software is affected? v1.0.0-beta.8

[aeneasr]

Thank you for the detailed explanation. This is indeed not supported at the moment but should be possible to be added without adding complexity in the consent flow.

[jandd]

The claims request information is passed in the claims request parameter and is available in the consent information returned by https://www.ory.sh/hydra/docs/reference/api/#get-consent-request-information this would allow an idp to parse it and only give the information that is allowed by the user in the AcceptConsentRequest body. Filtering the responses (ID Token and UserInfo endpoint) on the Hydra side would be nice though.

[jandd]

I added claim request support to my IdP PoC at https://git.dittberner.info/jan/hydra_oidc_poc. The resource application requests a claim in a getRequestedClaims function and the consent handler of the IDP part handles the check for requested vs. granted claims in its fillTokenData function. I implemented some helper functions for building the expected JSON structure in a separate package. Feedback is welcome :slightly_smiling_face:

[github-actions[bot]]

I am marking this issue as stale as it has not received any engagement from the community or maintainers in over half a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you for your understanding and to anyone who participated in the issue! 🙏✌️

If you feel strongly about this issues and have ideas on resolving it, please comment. Otherwise it will be closed in 30 days!

[aeneasr]

Marked as stale in error.

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneous you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️