<div dir="ltr"><div><div class="gmail_default" style="font-family:monospace">Hi, thanks for your reply.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Yes, it seems that the app is not behaving  like an openid app, but like an app that makes plain oauth2 authorization requests.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">In that case, after removing openid from scope and setting requireAuthenticationRequestPredicate to false i'm getting the warning <b>"unable to produce a viable "sub" claim"</b> and the error<b> "Subject may not be null" . </b>Removing the openid from scope, is supposed to not produce a sub claim, correct? </div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">What am I missing here? </div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thanks for your help</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Best</div><div class="gmail_default" style="font-family:monospace">Pedro </div><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><pre cols="72" style="white-space:pre-wrap"><p dir="ltr" style="color:rgb(136,136,136);font-size:13px;line-height:1.656;margin-top:0pt;margin-bottom:0pt"><br></p></pre></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Henri Mikkonen <<a href="mailto:henri.mikkonen@nimbleidm.com" target="_blank">henri.mikkonen@nimbleidm.com</a>> escreveu (sexta, 10/10/2025 à(s) 07:20):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Pedro,<br>
<br>
If the application is reading the claims from the JWT access token, it <br>
sounds like it's not really an OpenID Connect application? If that's the <br>
case, you should drop the 'openid' scope out from its scopes. Then the <br>
JWT access token will be automatically targeted to one of its resources <br>
and will contain the claim values. Obviously id_token will not be <br>
included in the token response anymore as it's not an OIDC sequence.<br>
<br>
For the record, one may also use the messageHandler [1] [2] profile <br>
configuration option for wiring a custom function that adds the <br>
resource-parameter on the application's behalf.<br>
<br>
BR,<br>
Henri.<br>
<br>
[1] <br>
<a href="https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3785326593/OPMessageHandling" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3785326593/OPMessageHandling</a><br>
<br>
[2] <br>
<a href="https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3921641530/OPProfileConfiguration-Common" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3921641530/OPProfileConfiguration-Common</a><br>
<br>
On 9.10.2025 21.21, Pedro Miguel Marques via users wrote:<br>
> Hi,<br>
> <br>
> Apologize for returning to this.<br>
> <br>
>    Is there any way to include the claims defined in the scope directly <br>
> in the jwt access token, without having to specify the |resource| <br>
> parameter in the authentication request? The third-party app we're <br>
> integrating with Shibboleth's OpenID layer is built to read user-related <br>
> claims like email straight from the jwt access token and doesn't support <br>
> the |resource| parameter in the auth request.<br>
> <br>
> <br>
> <br>
> thanks in advance for a reply<br>
> <br>
> Best regards<br>
> <br>
> Pedro<br>
> <br>
> <br>
> <br>
> Cantor, Scott <<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a> <mailto:<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>>> escreveu <br>
> (quarta, 24/09/2025 à(s) 15:01):<br>
> <br>
>      > Because the application from a third party, that we are<br>
>      > integrating with our OIDC OP, needs to get the email claim<br>
>      > from the acessToken. Does it make sense? It should be like<br>
>      > this?<br>
> <br>
>     The only case in which you would need the claim would be if that<br>
>     system you're logging into is then going to use the access token<br>
>     with a third system via an API that requires an OAuth token and will<br>
>     be verifying the JWT itself and wanting the claim (and email isn't<br>
>     the right information anyway, that's not an identifier).<br>
> <br>
>     If there are only two systems (OIDC client, OP) there is no scenario<br>
>     in which it's appropriate for that system to be looking at the<br>
>     access token, it's an opaque blob to any client.<br>
> <br>
>     -- Scott<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>