Closed nsklikas closed 3 days ago
IMO client's that would like the know the client_id that the token was issued for, should use the introspection endpoint.
no opinion of my own on that, would have to read around what's common practice, maybe @BarcoMasile can share his own experience here
overall looks good anyway
@nsklikas @shipperizer I agree, adding client_id info to the userinfo doesn't make sense and would be kind of a "misuse" of the userinfo endpoint. Having the audience is what's needed and with this PR we're good to go
IAM-909
Add client_id to access token's audience. Before the change, a jwt access token would be
The userinfo response:![image](https://github.com/canonical/identity-platform-login-ui/assets/19745916/86273888-0b3c-42c0-b6da-dbda37e55e8a)
After the change, the access tokens are like:
The userinfo resp:![image](https://github.com/canonical/identity-platform-login-ui/assets/19745916/b1e4d8e9-65a4-4928-b2a0-7f9d6a1f9772)
As you can see the
client_id
is automatically added to the ATaud
and the userinfo remains the same. I thought about adding theclient_id
to the userinfo as well, but that would go against the purpose of the endpoint (the client_id is not connected to the user's information). IMO client's that would like the know the client_id that the token was issued for, should use the introspection endpoint.