Setting custom claims on a remembered session

[tbalasavage]

When a user enters the OIDC auth flow, and they are remembered, it doesn't appear that the custom claims set during their initial authentication are automatically applied to the tokens that are returned to the client. For example, if I set a custom claim on the ID token for temperature (thought experiment only), and the temperature was 20 C, the ID token when they authenticate will contain a "temperature": "20 C" claim.

If later that evening the client submits an authentication request on their behalf, and the user is already authenticated, the claim isn't magically added somehow to the token. It appears that I need to set the Session property on the AcceptConsentRequestagain wiht a potentially different temperature (e.g. "temperature": "10 C"). Is that the expected behavior? I suppose that if I wanted to obtain the previous claims, I'd need to list the previous consent sessions and obtain them from there. Is that also correct?

[Kuvaldis]

I'd like to extend this question because it seems to be related to my case. Here is the scenario:

1. Suppose I'm logging in first time (both login and consent challenge response return skip=false) during consent flow I set some extra fields for id token and access token in Session. Let's say, I'm adding field a=b to both access and id token.
2. Next, my oauth2 client (web) has expired session, but Hydra session still there, so on new login challenge I receive skip=true.
3. My login/consent provider has to accept consent in the same way as in step 1, that is add a=b to access and id token. However, let's imagine such key/value is not known (say, they come from user during usual login when skip=false).

Question: how do I get them from previous authentication? Here I see two options:

1. Use endpoint /oauth2/auth/sessions/consent?subject=123 to get all sessions and lookup the current one by login_session_id (it is available from login/consent challenge responses). Problem here is if I in the future add some other fields using Session (accept consent request), they do not appear in mentioned endpoint response. Is it done on purpose? Does it mean that session is immutable (except I think for case when I'm using refresh token grant).
2. Somehow store these extra fields in login/consent providers, that is extend Hydra basically. Wouldn't really like to do so as it may cause other problems.

Any thoughts on how to propagate Session data from previously issued tokens to newly created when skip=true?

[vinckr]

Hello @tbalasavage
Apologies for the late reply.
I am not sure if that can answer your question, but here are some previous discussions around custom claims (for client credentials flows) :
#1748
#1383
#1022

Using the list consent sessions endpoint seems a good way to solve get the previous claims.

@Kuvaldis

Is the problem that in step 3. the consent screen is skipped (skip=true) and the extra fields for id tokens are not set?
In that case my gut reaction is to rather add that information outside of the auth flow, say in an extra UI -> e.g. we need some extra information to complete profile.

See also the threads on custom claims linked above.
This may be a good usecase for Ory Oathkeeper hydrator?

[Kuvaldis]

That's not exactly the case. To be more specific, we are using different types of accounts, that is from different account systems. To distinguish between them we use a custom claim, that is, provider=system1 or provider=system2.
So, when one already has a hydra session, that is, logged in with account from system2 and skip=true, we'd like not to ask them to provide some extra information. But, at the same time we don't know which system they've been logged in with, we only know subject, from which we cannot figure out what system the account belongs to.
The only place where I found this info is present is when I use Hydra admin endpoint /oauth2/auth/sessions/consent?subject=123. But since there might be any number of sessions for the same subject it's kind of not really convenient to scroll through all sessions.
Another problem as I described, is that session is never updated, even if I accept consent with another set of claims.

Lookup session

GET /oauth2/auth/sessions/consent?subject=123
[
    {
        ...
        "session": {
			...
            "id_token": {
                "claim1": "value"
            }
        },
        "remember": true,
        "consent_request": {
            "context": {
                "claim1": "value"
            }
        }
    }
]

Submit other set of claims

PUT oauth2/auth/requests/consent/accept?consent_challenge=2bdb65cab7724756bef131232df6abe4
{

    "remember": true,
    "remember_for": 1110000000,
    "session": {
         "id_token": {
                "claim1": "value1",
                "claim2": "value2"
          }
    }
}

Lookup session after consent submit

GET /oauth2/auth/sessions/consent?subject=123
[
    {
        ...
        "session": {
			...
            "id_token": {
                "claim1": "value" // same as before, while id token contains claim1 and claim2
            }
        },
        "remember": true,
        "consent_request": {
            "context": {
                "claim1": "value" // same as before
            }
        }
    }
]

[aeneasr]

@tbalasavage correct - it is expected that, on consecutive consent flows, the session data is provided by the consent app. We only carry over data on refresh requests as we are 100% certain that the information should be carried on in this step. For consent, this is very different for every application and can thus not be set automatically.

[aeneasr]

Regarding the other questions in this thread, we want to introduce a field such as past_session or something which would include information about the previous consent session and context. That way you hopefully have more context about what happend earlier :)