https://tools.ietf.org/html/rfc6750
1.2. Terminology
Bearer Token
A security token with the property that any party in possession of
the token (a "bearer") can use the token in any way that any other
party in possession of it can. Using a bearer token does not
require a bearer to prove possession of cryptographic key material
(proof-of-possession).
All other terms are as defined in "The OAuth 2.0 Authorization
Framework" [RFC6749].
1.3. Overview
OAuth provides a method for clients to access a protected resource on
behalf of a resource owner. In the general case, before a client can
access a protected resource, it must first obtain an authorization
grant from the resource owner and then exchange the authorization
grant for an access token. The access token represents the grant's
scope, duration, and other attributes granted by the authorization
grant. The client accesses the protected resource by presenting the
access token to the resource server. In some cases, a client can
directly present its own credentials to an authorization server to
obtain an access token without having to first obtain an
authorization grant from a resource owner.
The access token provides an abstraction, replacing different authorization constructs (e.g., username and password, assertion) for a single token understood by the resource server. This abstraction enables issuing access tokens valid for a short time period, as well as removing the resource server's need to understand a wide range of authentication schemes.
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
interaction between the client, resource owner, authorization server,
and resource server (described in [RFC6749]). The following two
steps are specified within this document:
(E) The client requests the protected resource from the resource
server and authenticates by presenting the access token.
(F) The resource server validates the access token, and if valid,
serves the request.
This document also imposes semantic requirements upon the access
token returned in step (D).