client_id Claim in a JWT Access Token

Three claims name parties and they are routinely mixed up. sub is who the token is about, usually the end user. aud is who is meant to consume it, usually an API. client_id is which registered application asked for it. In a client credentials grant there is no user at all, so sub is often set to the client identifier too, and that coincidence is where the confusion usually starts.

RFC 9068, the profile that standardizes what a JWT access token looks like, makes client_id required, along with iss, exp, aud, sub, iat and jti. That gives a resource server a reliable answer to which application is calling, which is what audit logs and per client rate limits need. Without it, a resource server can only see the user and has to infer the caller from context.

It also enables authorization rules that depend on the application rather than the person. A finance API may accept the same user through an interactive dashboard but refuse an unattended batch client, or apply different limits to each. Those rules are only sound when the client identifier comes from the signed token, since anything sent in a header alongside it can be changed freely by the caller.

In an ID token the equivalent question is answered by azp, not client_id, because ID tokens describe an authentication rather than an API grant. The decoder shows whichever the issuer emitted, under Custom claims, with the raw value. Seeing which of the two is present is often enough to work out whether you are looking at an ID token or an access token.