Compared to a large unique number, which is the subjectId by default, is it very bad if I simply store the primary key column in there? For some users, that value will be 1, for others, 9480, but hardly will it ever be something as huge as the default subjectId. It's an auto-identity column, so you can imagine in what way it behaves.
If it's bad-practice, please explain why, as I don't see a reason for having an additional column filled with these attributes. The token should be protected by a signature, so they can't abuse this in any way?
From the specification:
A Subject Identifier is a locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.
So the Id of a user suits perfect, which is also the default value used for sub. And you are free on how to implement the Id (e.g. Guid or int). But there is more in the specification:
Two Subject Identifier types are defined by this specification:
public
This provides the same sub (subject) value to all Clients. It is the default if the provider has no subject_types_supported element in its discovery document.
pairwise
This provides a different sub value to each Client, so as not to enable Clients to correlate the End-User's activities without permission.
IdentityServer uses public subs by default. If you are concerned about privacy you can switch to pairwise subs.
However, at the moment client specific subjects are not supported by IdentityServer. This seems to be planned for a future release, as discussed here.