Re: [Unity-idm-discuss] Claims in id token

[Marcus H. <ha...@ki...>]

On 21. Feb 2022 12:03, Krzysztof Benedyczak wrote:
> And here the remaining part of the original thread, related to extra claims
> in id/access tokens.
> 
> W dniu 21.02.2022 o 11:42, Sander Apweiler pisze:
> > > > > The second request we got is about user attributes within the
> > > > > token. The user, who made the request told us that the targeted
> > > > > software does not support requests to userinfo endpoint and does
> > > > > not keep consistent information about the user. For this they
> > > > > need information about the user in the token itself. I got the
> > > > > friendly hint that WLCG does it in this way. We already talked
> > > > > in the past about the possibility to add own claims. Maybe the
> > > > > better solution would be supporting the request parameter to
> > > > > allow SPs to request the needed claims itself instead of adding
> > > > > some claims in general. Would this be an option for unity?
> > > > We have a ticket on that already recorded, and is on the top of
> > > > open source queue.
> > > > 
> > > > Although we understand this bit differently. We were thinking
> > > > about server-side controlled setting to include some of the claims
> > > > (attributes) in the id token (applies to oidc mode only). Perhaps
> > > > configured per scope (as we have attributes bound to scopes).
> > > > 
> > > > Putting client in control of that sounds as a bit of an overkill.
> > > > Especially if you want to allow client to pick and choose which
> > > > individual attributesshould go into id token. Is there a strong
> > > > use case for that?
> > > I guess this goes a bit like the scopes clients can request to be
> > > available in the userinfo endpoint.
> > > 
> > > The current headache this brings up for the AccessTokens is that we
> > > have two compeing use cases. One would like to have all
> > > authorisation statements inside the token, so it never ever needs to
> > > contact the OP, while the other needs tokens below the 1k limit.
> > > 
> > > Both of these use cases can be asked to work around this. I don't
> > > have a strong opinion here.

> > I guess the first ticket was also initiated by me. The first Idea was
> > to have it under server control, because it was "only" groupmembership
> > information which was needed by some services. In meantime other
> > services requests other attributes in the access token.
> > 
> > Putting more information in the AT, the large size of it creates
> > problems for some other service. For this reason we do not want to put
> > to many additional attributes in the AT. In the best case only the
> > attributes which are needed by the specific service. For this the
> > services need a way to signal it to unity. Of course the unity
> > administrators must be able to limit/configure which attributes could
> > be released within the AT.
> > 
> > I don't know if the specification contains something about this. If not
> > hinting the needed attributes in the token via specific scopes might be
> > a way.
> 
> Well, so it seems we have a small confusion. Id token, or JWT access token?

Here it's about attributes in the JWT acess token.

> For the other part of the question, i.e. how to request and or configure it
> seems that this is strongly client-specific. So why not tho have this switch
> per-client? Sounds as the easiest way forward.

Client specific could cause problems. Assume oidc-agent is the client in
two cases, once for ssh (AT < 1k required for the time being) and once for
data access (server wanting to check authorisation offline).

I'd rather let the client request the scopes that it needs. Then the
corresponding claims will be sent, no?

E.g. I'd pick a subset of the advertised scopes in https://login.helmholtz.de/oauth2/.well-known/openid-configuration


> Configuration with scopes would also work, but would require more dev work,
> and then more configuration (admin would need to double number of scopes, to
> have variants with a thin token, or fully packed.

Hmm. I'm not sure I understand this.

-- 
Marcus.