But in this scenario, the “audience” of the token is the resource server’s ID,
right? And not the original client’s client id. This is a case where the RS is
:also: a client, because of the token exchange bit, but you can’t say the
audience is always going to be a client ID because most
To add some color, here there's a concrete scenario where many of those
concepts come together (or collide, if you prefer).
Azure AD implements am early draft of token exchange, largely for
implementing a cloud friendly version of kerberos constrained delegation-
say a native client calls a mid
There’s a difference in the intended audience of the access token in OAuth vs.
the ID token in OpenID Connect. In OIDC, the ID token is read by the client, so
the audience of the ID token is the client’s ID. That’s the only party reading
that token, in the usual case. In OAuth, the access token
It's not uncommon for a resource server (or API or protected resource) to
have a client id established with the AS. Typically that's used in the
context of the resource server acting as a client (and authenticating with
the AS) when calling the AS for access token introspection. Using that id
as
Hi all,
I have some questions/thoughts on the new draft for resource indicators.
I didn’t do an in-depth study but would like to share my thoughts with you
anyway.
1. In this draft, the Resource is identified by ‘resource’ parameter. For
example, when the resource is an API, I would expect
