Closed DigitalFlow closed 3 years ago
In this context, the client is not the API caller, but the API itself (think client of the introspection endpoint).
So this would not make sense.
Hi @leastprivilege,
thanks for your response. So if I understand you right, if my API itself had the client Id "myapi" as aud in tokens that are issued to it, I would pass "myapi" to the introspection endpoint? In my case there are multiple audiences that I have to accept, which is probably the reason for this confusion.
Because right now requests seem to be rejected with 401 if the aud inside the tokens does not match the client id during the introspection.
Thanks a lot for your help.
Kind regards, Florian
Which token service are you using?
We are using ForgeRock
I do not know the relationship between introspection, audiences and APIs in ForgeRock.
But the introspection spec says that the introspection endpoint should require a credential - and only the claims "belonging" to that credential should be returned.
Sending multiple credentials does not make sense to me. And it is not about the caller of the API - but the API itself.
Hi @leastprivilege,
thanks for your answer.
In that case I understand that the clientId that we send is only for authenticating ourselves to the introspection endpoint, not for actually using it inside the validation. That is fine, I'll close this issue and go through the Forgerock docs to find out whether there is anything handled differently in regards to audience handling in introspection.
Thanks for your help!
Kind regards, Florian
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue.
Hi,
we use this library for handling authentication in our Web service.
Now we have consumers for our API which have multiple client IDs that they want to use for accessing our API. The ClientId property of the introspection options is currently a string, which prevents us from doing this.
Our code currently looks something like this:
This works for us, but it's probably unnecessary, as the Authority is the same and only the ClientId to validate is different. With our implementation as above we always have additional (probably unnecessary) calls to our Auth sever.
Should I send a PR for a new options Property
ClientIds
which allows for multiple allowed ClientIds, or is that something that you would not want to see implemented?Kind regards, Florian