OAuth 2.0 overview

Learn about OAuth authorization framework. Get to know what kind of roles are in the OAuth framework. Get familiar with the flow concept and see examples.

In a nutshell

OAuth 2.0 is an authorization framework that allows third-party applications to obtain limited access to services. Such access can be granted either on behalf of a resource owner, for example, a user, or by allowing the third-party application to obtain access on its own.

OAuth is designed to be a secure alternative for sending authentication data directly from a client to a server. During such process a client can read or store resource owner’s credentials. OAuth mitigates the risks of data breaches that come from sharing credentials. It serves as an additional security layer created solely for authorization and it separates the role of a client from that of the resource owner, as the client is issued a different set of credentials than those that the resource owner has.

Roles

OAuth authorization framework defines four roles:

  • Resource owner, which is an entity capable of granting access to a protected resource, for example, a user.

  • Resource server, which is the server hosting protected resources, for example, APIs.

  • Client, which is an application that requests resources from a resource server after getting authorized by the user.

  • Authorization server, in this case, ACP, is the server issuing access or ID tokens after successfully authorizing and authenticating the client. To learn more, see the authorization servers documentation.

Flow example

Abstract Protocol Flow

The example flow diagram above presents the interactions that occur in the ACP OAuth authorization code grant flow. Some steps may differ between different kinds of flows. To learn more about a specific flow and its steps, see the flows documentation.

  1. A user tries to access the application (the client).

  2. The client sends an authorization request to the authorize endpoint. .

  3. ACP displays a consent screen for the user.

  4. The user gives their consent.

    Note

    Authorization grant is a credential that represents the resource owner’s authorization. To learn more, see the flows documentation.

  5. ACP issues an authorization code.

  6. The client requests authentication to the token endpoint using authorization code provided in the previous step.

    Read more

    To learn more, see the client authentication documentation.

  7. ACP validates the request.

  8. ACP returns the token.

  9. The client requests protected resources from the resource server and presents the token it received in the previous step.

  10. The resource server validates the token and responds with requested resources.

Token scope

Both authorize and token endpoints have an optional scope parameter. It allows the client to specify the scope of the access request. ACP grants access token with the scope that was requested.

ACP can fully or partially ignore the scope of the request depending on the authorization tenant’s server policy or the resources server policy. In any case, the client is informed about the difference between the issued and the requested access scope.

For the client credentials and the jwt_bearer grant type flow, if the requested scope parameter is empty, implicitly, all scopes that are assigned to the client are requested except the dynamic scopes and the offline_access scope.

ACP also features dynamic scopes to enable the access control at the coarse-grained level. To learn more about it, see the dynamic scopes documentation.