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.
Basically, the authorization process is as follows:
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.
There are two token types in the OAuth 2.0 authorization: Access Token and Refresh 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:
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 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.