Skip never true after accepting the first consent challenge with remember=true

Hi all,

I’m going crazy now for a few days and need some help. Why oh why when I accept a consent challenge after accepting a login challenge, with both marked remember true and for 3600, does the second attempt never return skip = true?

I’m not changing anything client side, but am using AppAuth and PKCE. Is it the PKCE making the consent request look difference to Hydra?


I think this may be the case as PKCE isn’t a clear cut as a client id with a client secret?

I’ll check this SQL:

So running this by hand inside the docker pg container putting my subject and native app client_id in the SQL placeholders returns this:

-[ RECORD 1 ]--------+----------------------------------------------------------------------------------------------------------------
challenge            | 99fc2131ef4b4d149b13c7ab2be93782
granted_scope        | openid|offline
remember             | t
remember_for         | 3600
error                | {}
requested_at         | 2020-05-20 13:19:07.036145
session_access_token | {"realm":"testing"}
session_id_token     | {"email":"[email protected]","fullname":"Gavin Henry","name":"Gavin","surname":"Henry","username":"gavinhenry"}
authenticated_at     | 
was_used             | t
granted_at_audience  | 
handled_at           | 2020-05-20 13:19:29.13488

so any ideas why I get asked for consent again within the 3600 secs @hackerman


What version are you running?

1 Like

5661ec3b / master running a modified quickstart.yml from the 5 min demo.

Oh I get it now - you’re using a public client without a secret?

That’s right. Using AppAuth with PKCE and code challenge hashes etc

The consent remember feature is not available for public clients, only for private ones. I believe there’s even an OpenID Connect Conformity check for that, which is required to pass certification.

1 Like

Yup, this is documented at that specific code line:

We should definitely document this though. Maybe in the advanced section on public clients?

1 Like

This sentence is hard to grok :slight_smile: If the public client sends prompt=none and Hydra returns consent_required ???

Bottom line is consent can never be skipped on a public client, i.e. just a client id and no secret (PKCE used too)?

Reading more into the comments there, should “authentication” be skipped either on a public client?

Just below that comment, if the scheme is https, consent can be skipped?

If an HTTPS redirect URI is required instead of a custom scheme, the same approach (modifying your AndroidManifest.xml) is used:

Re docs, yes, in the Login and Consent Flow documentation and advanced. Anywhere that mentions skip=true really :slight_smile:


Yes, that is how the OpenID Connect tests demand it, even with https. At least as far I remember, it’s been a while. Happy to take another look if you point me to docs / certification that proves otherwise.

1 Like

Sorry, scrap the https comment - for https this is not the case.

I’m guessing you’re using a custom redirect scheme for your app?

So you can skip with https which, with public clients using AppAuth (native apps on mobile), it is the preferred way, then you can fall back to custom schemes according to the docs.

Yeah, that’s what AppAuth needs. It can be https though, as per the examples I linked to before.

If an HTTPS redirect URI is required instead of a custom scheme, the same approach (modifying your AndroidManifest.xml) is used:

        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <category android:name="android.intent.category.BROWSABLE"/>
        <data android:scheme="https"

HTTPS redirects can be secured by configuring the redirect URI as an app link in Android M and above. We recommend that a fallback page be configured at the same address to forward authorization responses to your app via a custom scheme, for older Android devices.

Ok, so then silent refresh works with that workaround? Is there another issue or is that the solution

If you mean with a refresh token, yep. For me, I’m using a custom scheme and not the https one yet as discussed in that guide. Because I need session and id data in the consent reply and consent can’t be skipped (, I have to always ask for a fresh login.

That’s no problem though as I have a refresh token. What use cases are there for the skipping login anyway? I suppose if you’re not allowing offline access?


Is it accurate that public clients (missing a client_secret) with a non https redirect scheme can never be verified and should always prompt users for their consent?

1 Like