Hi Brian
Thanks, 'cid' is a proper compact name :-), I've made our code
configurable - to support reporting a client_id property either as a
'client_id' or 'cid' claim.
Cheers, Sergey
On 12/08/16 23:30, Brian Campbell wrote:
Yeah, the client typically isn't the/an audience of an access toke
Yeah, the client typically isn't the/an audience of an access token. The AT
is opaque to the client and the client never processes or validates it. So
aud would have the resource(s) and something else could carry the client
id.
FWIW, token exchange is looking to define and register "cid" as a JWT
Hi,
After updating my earlier code (where 'client_id' was set as the
standard JWT access token 'aud' property) to use 'aud' to represent the
resource audiences I'm now thinking how to represent a 'client_id' in
this token.
For now if I'm using a 'client_id' claim, to be consistent with a
s
Hi John
On 11/08/16 23:24, John Bradley wrote:
I think most people put the a resource URI in the aud.
Connect uses the client ID as that is bit more stable than trying to use a
redirect URI when there could be multiple ones.
Given that a resource server doesn’t typically have a client_id the re
I think most people put the a resource URI in the aud.
Connect uses the client ID as that is bit more stable than trying to use a
redirect URI when there could be multiple ones.
Given that a resource server doesn’t typically have a client_id the resource
uri make a reasonable value.
You could
Hi All
Awhile back I was asking why would self-contained JWS JWT access tokens
would be used (as opposed to JWE JWTs), my concern was that anyone with
a JWT library can read this token's content - but as I was explained
that should not be a problem if such a JWS JWT token contains
non-sensiti
