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

[Krzysztof B. <kb...@un...>]

Hi,

I'm leaving the longer thread below for reference, however the main open 
point is how to specify what should land in JWT-style access token.
I see no security implications here, so that's not a problem.

 From what you wrote configuring that via scopes is not great as would 
make it hard for the clients.

Configuring per client is not acceptable as the same client may operate 
in different contexts and in some it is using some dumb services which 
have a limit on access token size.

So what are the proposals here? Use some proprietary request parameter 
for it?

Cheers,
Krzysztof






W dniu 22.02.2022 o 08:08, Sander Apweiler pisze:
> Good morning,
>
> On Mon, 2022-02-21 at 17:29 +0100, Marcus Hardt wrote:
>> 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.
> Yes JWT access token. Sorry for the confusion. Writing email between
> several meetings is no good idea. :(
>>> 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
>>
> I guess the problem is that at least some services reuse token, e.g.
> from oidc agent. So client specific won't work fully. At least for one
> service I know the users use the oidc agent to get the token for the
> service. Another service which requested this feature did have it's own
> client registered.
>>> 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.
>>
> I'm not sure if the administrativ overhead is that much for service
> administrators. Because they configure once which scopes their service
> need. I think the overhead is on side of the not technical experts,
> using the oidc client, which need to adopt the requested scopes for
> each new access token, according to the service they want to use.
>
> Best regards,
> Sander