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.
What OAuth Is
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.
OAuth Flow Participants
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 is the server issuing access or ID tokens after successfully authorizing and authenticating the client.
How Applications Get Tokens to Access Resources
OAuth client applications can utilize different OAuth and OIDC grant types (also called flows) to authenticate themselves and/or get authorized to access the protected resources. During such flows, client apps must send requests to the authorization server APIs depending on the process of the grant type. To further enhance the security of the data, authorization server may also require from applications to use different OAuth extensions like, for example, PKCE, Pushed Authorization Requests (PAR), and more.
Token Scope
Both authorize and token endpoints have an optional scope parameter. It allows the client to specify the scope of the access request. SecureAuth grants access token with the scope that was requested.
SecureAuth 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.
SecureAuth also features dynamic scopes to enable the access control at the coarse-grained level.