OAuth 2.0 is called an authorization “framework” rather than a “protocol” since the core spec actually leaves quite a lot of room for various implementations to do things differently depending on their use cases. Specifically, OAuth 2.0 does not provide a mechanism to say who a user is or how they authenticated, it just says that a user delegated an application to act on their behalf. The OAuth 2.0 framework provides this delegation in the form of an access token, which the application can use to act on behalf of the user. The access token is presented to the API (the “resource server”), which knows how to validate whether the access token is active. From the application’s perspective, it is an opaque string.

When you check in to a hotel, you get a key card which you can use to enter your assigned room. You can think of the key card as an access token. The key card says nothing about who you are, or how you were authenticated at the front desk, but you can use the card to access your hotel room for the duration of your stay. Similarly, an OAuth 2.0 access token doesn’t indicate who a user is, it just is the thing you can use to access data, and it may expire at some point in the future.

OAuth 2.0 was intentionally designed to provide authorization without providing user identity and authentication, as those problems have very different security considerations that don’t necessarily overlap with those of an authorization protocol. Treating authentication and identity separately allows the OAuth 2.0 framework to be used as part of building an authentication protocol.