No claims released when attribute release consent flow is enabled for OIDC.SSO profile
Description
Environment
is related to
Activity
Scott Cantor March 16, 2022 at 5:25 PM
The code is now recognizing a new flag added to the API that gets set (or should, that’s the linked issue) if the per-request consent option is chosen. That overrides the normal setting to encode consent, making that unnecessary for server-side storage situations.
Scott Cantor August 2, 2021 at 10:01 PM
It's still a bug, we just have to consider how to approach it, whether it's documentation or just maybe forcing the option "on" when that particular sequence occurs.
Keith Wessel August 2, 2021 at 9:38 PM
Sure enough, with idp.oidc.encodeConsentInTokens = true, I do in fact get claims. I have no idea what was different in my test with this set to true last week, but it works fine now. This all makes sense, too. I'd suggest that you keep others from shotting themselves in the foot like I did and document this in the comments of oidc.properties or, better yet, for this property's documentation in the wiki.
Thanks, and sorry to have wasted your time on this.
Keith Wessel August 2, 2021 at 4:24 PM
Right; makes sense. But I thought I tried setting the option to store it to the tokens to true, and it still didn't help. I'll try that again this afternoon and report back. Honestly, storing to the tokens makes more sense for OIDC, anyway, and not just because of this fundamental issue. As you said on the list, it saves a lot of extra database calls and makes mroe a more efficient call to the IdP.
I'll report back this afternoon.
Scott Cantor August 2, 2021 at 4:20 PM
There's no way the IdP can know whether you consented if there's no record stored and you don't store it in the tokens. QED.
It worked before because the code was completely different before and effectively always stored the decision in the tokens (though with some other bugs).
So, in the end, you'd have to store it in the tokens for now, just change that option.
When the attribute release consent post authentication flow is enabled for the OIDC.SSO profile, no claims are released to the client based on requested claims or scopes. The only claims released are the reserved claims plus any that are not configured to be displayed on the consent screen. For instance, we release a value of eduPersonEntitlement to all OIDC and SAML clients, and it's configured to not appear on the consent screen. It makes it through. But those listed on the consent screen such as givenName and SN (mapped to their apropriate OIDC claim names, of course) aren't released. Turning off attribute-release for the OIDC.SSO profile allows the claims to be released. I was unable to produce any logs that I thought helped to illustrate this problem well, but I can dig more if needed.