User Consent and Skip with id_token and access_token session data always needed?

Hi all,

I’m just cleaning up what I’ve done in OAuth 2.0 Authorize Code Flow + PCKE + AppAuth success. Thank you! and have an issue once a user has logged in and given consent (well, for a first-class app, consent is automatic in this example).

So my flow, as per the example Login and Consent app is working correctly for the first login and auto-consent, but the second time I do it I have an issue (it’s within the session length I set in login and consent of 3600s each).

Let me explain. User logs in and a session is created in our Login and Consent App. Consent challenge comes in after this, so I have a session cookie so I know who logged in. I want to know because I set things in the access_token and id_token session data that I PUT back to Hydra.

Once I have PUT the consent, I delete the session. The next time the user comes in, Login and Consent are marked skip, so no session is created between the two in our server, so I don’t know who the user is to PUT back exactly like I did the first time.

I think I shouldn’t have to add in the session data again in the next consent acceptance if it’s marked SKIP as I don’t have it.

Make sense? What are others doing there? Whether login or consent are marked SKIP or not, we seem to have to alway supply the same data in the consent acceptance which feels wrong to me. I know the subject, but without creating an authenticated session our side again, I don’t have access to all the user info that I want.

Does it get overwritten each time?

Thanks,
Gavin.

So there’s currently a session_id (or sid?) hint in the login/consent request payloads which is set if it’s a skippable request. You can use that to populate the request context. I do however agree that this should be automated / automatable. Mind opening an issue? :slight_smile:

1 Like

Hi @hackerman

In the login_challenge, session_id is always set. On the consent_challenge this comes through as login_session_id. These are ALWAYS there. I’ve compared a skip and non-skip consent_challenge.

Thanks.

Sorry, misread that. If skip is true, I’ll supply the login_session_id within the context.

Thanks.

Weird, my consent_challenge is never coming in marked skip. Checking what I send.

Oh, dear me. I’m not setting handled_at, so skip is always false, but still, I need to do what you’ve recommended.

Raised an issue:

Think I found two bugs I’ll raise. This field is required and isn’t triggering an error. If I supply no TZ it hates it.

I am not seeing consent_challenge ever being skip=true even with supplying handled_at the first time.

login_challenge has skip=true though after the first use.

Oh, it looks like I don’t need to supply handled_at as it’s generated server side:

I think my problem here is the consent challenge is never getting set to skip once the first challenge is handled:

I’m just figuring out what sets it to be “Handled.”

I just can’t get consent to ever be marked as skip. This is the JSON I’m sending:

{
   "remember":true,
   "grant_scope":[
      "openid",
      "offline"
   ],
   "remember_for":3600,
   "session":{
      "access_token":{
         "realm":"customers"
      },
      "id_token":{
         "name":"Gavin",
         "username":"ghenry",
         "email":"[email protected]",
         "fullname":"Gavin Henry",
         "surname":"Henry"
      }
   },
   "grant_access_token_audience":[

   ]
}

Why the next time the consent challenge comes in is it NOT marked as skip=true?

Any ideas @hackerman

Thanks.