Re: [Unity-idm-discuss] Addition to OAuth2/OIDC tokens

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

On 16. Feb 2022 23:03, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> let me ask for few clarifications.
> 
> W dniu 15.02.2022 o 15:26, Sander Apweiler pisze:
> > Hello Krzysztof,
> > hello Roman,
> > 
> > since our connected SPs are growing we do get further feature request,
> > which I want to share with you.
> > 
> > The first one is a possibility to change the aud of a registered
> > client. At the moment unity uses the registered username of the OIDC
> > client, which is fine according to the RFC. But there are connected
> > services which does the audience use, too. In this specific use-case
> > the token was generated by the user using the oidc-agent tool [1]. The
> > generated token was send via an API to dCache which validates the
> > token. dCache is also checking the audience and rejects all token
> > having an unsupported audience. The OIDC agent has an option the
> > request a specific aud value for the token and forwards this request to
> > the AS. Together with the request users showed us examples where Indigo
> > IAM do support this. Would it possible to implement this unity, too?
> 
> So for the support of multiple audiences per client - certainly that's
> possible. I understand that this is just a configuration of allowed
> additional audiences. Each of such audience should have its identifier and
> have to be returned. Easy.
> 
> Can you tell more what is the purpose of "requesting" of a specific audience
> by the client? I think it is some proprietary feature of Indigo IAM. We can
> have it, but sounds like a bigger work, and I need to understand the purpose
> and details of the use case. Also, technically, would that be just narrowing
> of the allowed audiences of the client? Shall that be then also presented on
> consent screen?

The aud claim is a bit weird.

In the oidc core spec I find it mostly in the ID Token, where "it MUST
contain the OAuth 2.0 client_id".

It does make sense to be mandatory, and to be the client_id for the ID
Token, because the ID Token is for that specific client_id only.


The aud claim is also used in JWT ATs, and therein became mandatory via
RFC9068[1] / RFC7519[2]. Just: The notion of the client_id isn't there,
because ATs may also be intended for others than only a specific
client_id. 
[1] https://www.rfc-editor.org/rfc/rfc9068#name-data-structure
[2] https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3

This lead the WLCG people to use it for their purposes [3]
[3] https://zenodo.org/record/3460258

Funny enough, [3] states 

    The contents of the claim may either be a string or URL; we do not
    currently provide specific guidance on selecting audience names.

Also, they forget to mention that it's a JSON list, not a space separated
list of strings.


By now, people started using it for different ways to specify who should
use the token.  dCache is already tokens that it considers not intended
for itself.

With the WLCG profile of Indigo-IAM this works "well".


With oidc-agent we simply allow users to specify what they want to have in
the token.

In the lack of an existing spec, oidc-agent first implemented something IAM
specific, and will move to useing RFC8707[4] to request specific scopes.
[4] https://www.rfc-editor.org/rfc/rfc8707


 
> > 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.

-- 
Marcus.