There is this code block in the OAuth 2 session handler, with very little explanation ("the access token was issued to a machine and represents no particular user"). We should document how such access tokens are generated and what they are used for.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
So apparently when access tokens are issued via the client credentials flow (that is, making an API call to /oauth2/access_token with the client ID and secret), the oauth2-server library issues an access token with no user ID (sub is the empty string), and does not create a ConsumerAcceptance record. This logic is to make sure that such access tokens are accepted.
This is broken in several ways: the access token will be anonymous (it will result in an anonymous session), passing an anonymous user breaks the contract of UserInfo::newFromUser(), the missing user ID will be inherited by refresh tokens and cause further problems. But presumably it was good enough for rate limit control via the OAuthRateLimiter extension, for clients which do read-only access and don't care whether they are authenticated.
Fixing it will happen in T417278: Choosing client credentials grant for OAuth 2 results in an access token (JWT) with the 'sub' field empty.