In a business setup, you want to limit access so that user can access only specific resources. In OAuth 2.0, you can defined access permissions depending on the user, the application, and the OAuth 2.0 scope.
You have registered your OAuth 2.0 client at the OAuth 2.0 authorization server.
The client must know the token endpoint.
The resource owner has configured the client so that it knows the resources it wants to access and the scopes to which they belong.
The user must be allowed to delegate access to these scopes to the respective OAuth 2.0 client.
In a sales environment, salespersons access an application in the AS ABAP that enables them to create invoices for business partners in their sales region. When working on the invoices, these salespersons should not be able to access or change business partner master data of another sales region. For this reason, the resource owner restricts the access to the resources by setting up different OAuth 2.0 clients and scopes for salespersons of different sales regions.
You are working as a regional salesperson in the cloud application, and this application needs to retrieve project data (resources: for example invoices, contract data, and business partner master data) from an AS ABAP back-end system. You do not want to directly authenticate at the AS ABAP, but instead want to use OAuth 2.0 access acting on behalf of yourself.
The cloud application accesses SAP Gateway using the OData protocol. SAP Gateway uses the OAuth 2.0 server role. Your OAuth 2.0 scope contains the resources A (invoices), B (contract data), and C (business partner master data). This data, which you need to work with frequently, is restricted to your sales region.
You use an OAuth 2.0 client to enable the cloud application to access the resources. You give the client a name that indicates the cloud application that uses it (for example, OA2_ClApp. This client is used to request an access token, to authenticate, and to transmit your scope (resources A (invoices), B (contract data), and C (business partner master data)) to the authorization server in the AS ABAP.
During authentication, an identity provider requests and gets an access token (in this case a SAML 2.0 bearer assertion) from the authorization server. The authorization server sends the SAML 2.0 bearer assertion to the resource server. The resource server checks whether you are authorized to access the resources A (invoices), B (contract data), and C (business partner master data) with OAuth 2.0. If this is the case, the AS ABAP back-end approves your request and makes the resources A (invoices), B (contract data), and C (business partner master data) for your sales region available.
Both, the authorization server and the resource server reside in the AS ABAP although they are separate components.
For more information, see Configuring OAuth 2.0.