Identityserver4: Populate sub claim for client credential flow

[leechen]

Using client credential flow I got back an access token with client_id but no sub claim. Based on OAuth2 spec https://tools.ietf.org/html/rfc7523
3.2.b , it seems sub should be the same as client_id. Is this a bug?

1. The JWT MUST contain a "sub" (subject) claim identifying the
   principal that is the subject of the JWT. Two cases need to be
   differentiated:
   B. For client authentication, the subject MUST be the
   "client_id" of the OAuth client.

[leastprivilege]

You are looking at the wrong spec. Check RFC 6749/OIDC.

Sub identifies a human. In client credentials there is no human. At least that's how we implemented it.

[leechen]

Not using client_id as sub works for me since it more unambiguous.

[CYarmock]

I understand this issue was closed, but we would like for it to be reconsidered.

RFC 6749 doesn't mention sub or subject (in the sense we are discussing here).

From @leastprivilege

Sub identifies a human. In client credentials there is no human. At least that's how we implemented it.

Although the subject might be assumed to be a human in OpenID Connect, an OAuth 2 subject is not a human, it is a _security principal_ (emphasis added):

(subject) claim identifying the principal that is the subject of the JWT.

A principal is _any_ entity that can be authenticated:

Security principals are any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account, or the security groups for these accounts.

From looking around at a few other Identity Providers, they include a sub claim, and it is the client_id when using the client_credentials grant.

We recently added this behavior in our implementation that is based off IDS4.

Any chance of having this request reevaluated and implemented?

Thanks!
-Chad

[TomCJones]

FWIW we agree with the OIDC definition of subject.

[leastprivilege]

IS is an OIDC and OAuth implementation. You can't see one of them in isolation.

Our default behavior uses sub to identify a human - and we think it is the right thing to do. Since you were able to change that behavior using our standard extensibility points, I don't think we need to change anything here.

[oleborne]

I think talking about RFC6749 or OIDC isn't relevant in the current topic because both do not define the form or content of the _access token_.

From RFC6749, section 1.4:

The string is usually opaque to the client. [...] Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification.

OIDC does not further specify the form and content of an access token but adds the notion of _ID token_.

The RFC that defines a way to use a JWT as _access token_ is indeed RFC7523, quoted in the initial request.

[leastprivilege]

You are right - we are talking about the combination of both and how to make them work in a real security system.

We made the decision to use sub to identify a human (also in access tokens) - and we actively decided against re-using it for identifying clients for special cases. We think that this ambiguity is error prone.

I hope this explains it once and for all.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.