Add email claim to Access Token oauth2

[Henri Mikkonen]

Hi Pedro,

If the application is reading the claims from the JWT access token, it 
sounds like it's not really an OpenID Connect application? If that's the 
case, you should drop the 'openid' scope out from its scopes. Then the 
JWT access token will be automatically targeted to one of its resources 
and will contain the claim values. Obviously id_token will not be 
included in the token response anymore as it's not an OIDC sequence.

For the record, one may also use the messageHandler [1] [2] profile 
configuration option for wiring a custom function that adds the 
resource-parameter on the application's behalf.

BR,
Henri.

[1] 
https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3785326593/OPMessageHandling

[2] 
https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3921641530/OPProfileConfiguration-Common

On 9.10.2025 21.21, Pedro Miguel Marques via users wrote:
> Hi,
> 
> Apologize for returning to this.
> 
>    Is there any way to include the claims defined in the scope directly 
> in the jwt access token, without having to specify the |resource| 
> parameter in the authentication request? The third-party app we're 
> integrating with Shibboleth's OpenID layer is built to read user-related 
> claims like email straight from the jwt access token and doesn't support 
> the |resource| parameter in the auth request.
> 
> 
> 
> thanks in advance for a reply
> 
> Best regards
> 
> Pedro
> 
> 
> 
> Cantor, Scott <cantor.2 at osu.edu <mailto:cantor.2 at osu.edu>> escreveu 
> (quarta, 24/09/2025 à(s) 15:01):
> 
>      > Because the application from a third party, that we are
>      > integrating with our OIDC OP, needs to get the email claim
>      > from the acessToken. Does it make sense? It should be like
>      > this?
> 
>     The only case in which you would need the claim would be if that
>     system you're logging into is then going to use the access token
>     with a third system via an API that requires an OAuth token and will
>     be verifying the JWT itself and wanting the claim (and email isn't
>     the right information anyway, that's not an identifier).
> 
>     If there are only two systems (OIDC client, OP) there is no scenario
>     in which it's appropriate for that system to be looking at the
>     access token, it's an opaque blob to any client.
> 
>     -- Scott
> 
> 
> 
> 
> 
>