OAuth access tokens on the other hand, are generated on a per-session basis. Being granted an access token by a secure authentication provider will not occur, until the provider has received proof that the requesting user is entitled to requested privileges; such proof might be established through knowledge of credentials (i.e. a corresponding username and password pair.) Other times, access control might be more restrictive and access tokens are only provided for a small sub-set of privileges within a particular app/site/API sub-component, area of operation, control sphere, etc. The permissions ultimately granted to the end user can be as fine-grained as the system administrator wishes. Note that access tokens are programmed to expire after a set amount of time and are capable of providing discretionary access control between various users/groups, privileges/capabilities, etc.
Access tokens are often transferred outside of the URL in the HTTP request header's Authorization field, for example. Sometimes, custom authentication framework implementations will cause the token to be transmitted within a cookie that has the HttpOnly, Secure and SameSite flags enabled--or as a custom HTTP request header such as X-Auth-Token as publicly documented for Oracle's Cloud Storage SaaS: Oracle's Cloud Storage Service API:
For these reasons, the complexity required to obtain access tokens from an authentication framework such as OAuth is much higher than what is needed to log the usage of an API key. Furthermore, the robustness of authentication and authorization frameworks allows the access token to be encapsulated within the HTTP protocol in ways that it is rather difficult to view or tamper with the token.