All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users, and a third subject: Groups. Kubernetes does not have objects (kinds) which represent normal user accounts. Normal users cannot be added to a cluster through an API call. Normal users are typically managed or authenticated through integrations with other authentication protocols such as LDAP, SAML, Azure Active Directory, Kerberos, etc. You can leverage an external identity provider like OIDC to authenticate through a token.

For Service Accounts, as you've correctly noticed, if you don't explicitly create a Kubernetes Service Account in your namespace, you'll only have access to the default service account, which will be default-token-<hash>.

A token is not automatically created for a "Normal User", but is automatically created for a Service Account. Service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials stored as Secrets.

Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins. As HTTP requests are made to the API server, plugins attempt to associate the following attributes with the request:

• Username: a string which identifies the end user. Common values might be kube-admin or jane@example.com.
• UID: a string which identifies the end user and attempts to be more consistent and unique than username.

The subject of user authentication is easier answered if we know what the user authentication integration being used is.