Re: [Unity-idm-discuss] Requesting token audience

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

On 21. Feb 2022 11:53, Krzysztof Benedyczak wrote:
> Gents,
> 
> As we have 2 topics here let me break the thread into two.

Many thanks (I was shocked by seeing the length of the email).
 
> Here audience goes
> W dniu 21.02.2022 o 11:42, Sander Apweiler pisze:
> > Good morning Krzysztof,
> > I'm sorry for the delay. There were a lot of meetings end of last week
> > and I had no time answer earlier.
> > 
> > On Thu, 2022-02-17 at 10:16 +0100, Marcus Hardt wrote:
> > > 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
> > > > 
> > > > 
> > Beside the specification hints from Marcus and the background for
> > implementing it in oidc-agent, I just can add that we had request from
> > different service providers, I guess all of them knows Indigo IAM, if
> > we could make the aud claim adjustable because they do want to limit
> > token acceptance to tokens which contain their service in the aud
> > claim. But all of this services are using command line and tokens which
> > was collected e.g. using oidc-agent.
> 
> @Marcus all you wrote is consistent with my understanding, however thanks
> for the RFC8707 link - I was missing that.
> 
> Having that the situation is much more clear: the request is to implement
> that RFC.
> 
> My doubts are around two aspects here:
> 
> 1. shall we have the allowed audiences preregistered per-client (or
> authorization server endpoint) in Unity? This will allow for control of
> which audiences are in general allowed for client as well as to present them
> in readable form on consent screen. -> My current thinking here is: no, that
> can be done later if/when needed.

Yes, I think I was this is what is also sometimes done for the allowed
scopes per client. But a) I'm not sure if there is (already) a valid use
case for this, and b) it causes more pain to the client registration
process.
Add-on-demand seems ideal.
 
> 2. shall we present requested audiences on consent screen? -> My thinking
> here is: yes, we should. Actually currently audience is restricted to the
> client itself, which can use the token on other services only if those
> services ignore audience claim. So if Unity will "officially" allow for
> additional audiences, it shoud inform about that.

Yes, that probably makes sense too (although, judging from myself, the
consent screen hardly receives the attention that it should).

-- 
Marcus.