During the OAuth 2.0 authorization process, the third-party application requests an access to a protected resource resided in a resource server. There are four sides involved in this process:

Resource server hosts the protected resource. For example, if a resource server is a cloud storage, the protected resource can be a file uploaded to that cloud.
Resource owner is a person who owns the protected resource. In case of the cloud storage, resource owner is someone who uploaded the file or who manages the cloud storage. Resource owner grants access to a protected resource.
Client is an application sending a request to a resource server to get or modify the protected resource. It can be a desktop application that downloads the file from the cloud storage. ReadyAPI is also considered a client application.
Authorization server issues an access token for the client, after a resource owner grants access.

Authorization process

Basically, the authorization process is as follows:

Click the image to enlarge it.

A client requests permission from a resource owner to access a protected resource. The owner’s permission is represented by the Authorization Grant.
The client sends the grant to the authorization server to get an access token.
Finally, the client uses the received token to access the protected resource.

The process flow shown above is an abstract model. The real authorization process depends on the used grant type. Thus, when the Client Credentials grant type is used, the client does not interact with the resource owner and uses its own credentials to get an access token.

Tokens

There are two token types in the OAuth 2.0 authorization: Access Token and Refresh Token.

Access Token

An access token is a string used for authorization and authentication when getting access to resources on the resource server. It can have different formats and structures based on the resource server security requirements.

There are two types of access tokens: bearer tokens and MAC tokens:

Bearer tokens are sent over HTTPS to ensure secure transfer even if requests are neither signed nor encrypted. A request with a bearer token is considered as having been authorized.
MAC tokens are more secure than bearer tokens. They are similar to signatures, as they allow you to perform partial cryptographic verification of requests.

Refresh Token

Refresh tokens are normally sent along with access tokens. Refresh tokens are used to get a new access token when the old one expires. Instead of performing the normal grant procedure, the client provides a refresh token and receives a new access token. Using refresh tokens makes expiration time for access tokens on the resource server shorter and expiration time for accessing the authorization server longer. To learn more, see Refresh Access Token.

Scope

Scope regulates the level of access to the protected resource. For example, one scope can give read access, while another one can allow modifying the resource. To specify a list of scopes, use a space-delimited string.

OAuth 2.0 Basics

Authorization process

Tokens

Access Token

Refresh Token

Scope

See Also