OIDC claims missing after upgrade to IdP 4.1

[Wessel, Keith]

You're referring to this:

# Store user consent to authorization code & access/refresh tokens instead of exploiting consent storage
#idp.oidc.encodeConsentInTokens = false

Are you suggesting having it set to false (default) could trigger the bug? Or if I had it set to true, that would trigger the bug?

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Tuesday, July 20, 2021 8:28 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: OIDC claims missing after upgrade to IdP 4.1

On 7/20/21, 9:22 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

> We do use a database for storing consent decisions, but obviously, the 
> consent post authentication flow isn't enabled for any of the token or userinfo non-browser profiles. I think I'm missing your point, though, on this.
> Can you explain, please?

There's a setting to encode attributes into the tokens so that they can be recovered without having to resolve them again, and I was thinking maybe that triggered a bug in the consent enforcement.

The tokens can also store the consent decisions I think to allow client side consent storage to work but I really don't know all the options or how they work.

Somewhere in some mix of settings is probably the bug.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!rDDnIIpdCfDfmwFL0XPiSQWDzlMVNZn6Rkv0sh2ut4x4qD-GlwqPNxH2tcMfouwEPA$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net