Show TOC

Authorization Code Flow for OAuth 2.0Locate this document in the navigation structure

This topic gives you an overview of the OAuth 2.0 grant type authorization code flow for accessing resources in the OAuth 2.0 server.

Prerequisites

If you want to use the authorization code flow for OAuth 2.0, you must make sure that the following prerequisites are fulfilled:

  • The OAuth 2.0 resource owner is a user of type Dialog in the AS ABAP.

  • The resource owner has the necessary authorizations to access the protected resources to be accessed by an OAuth 2.0 client.

  • During the registration of the OAuth 2.0 client, you have assigned OAuth 2.0 scopes in Scope Assignment.

  • You have authorized the resource owner to delegate access to an OAuth 2.0 client.

  • The OAuth 2.0 client must be identical to a user of type System.

  • You have activated the grant type authorization code in the OAuth 2.0 client registration.

  • You have registered an endpoint of your OAuth 2.0 client web application as a redirection URI in the OAuth 2.0 client registration.

  • You have installed an application that supports OData on AS ABAP, such as SAP NetWeaver Gateway.

For more information, see SAP Note 1688545 Information published on SAP site and Configuring OAuth 2.0.

Procedure

You want to allow a browser-based web application that acts as an OAuth 2.0 client to access a selection of protected resources hosted on an AS ABAP. The web application itself can either be hosted on-premise or in the cloud. OAuth 2.0 allows resource owners to delegate a subset of their permissions to an OAuth 2.0 client without sharing their credentials (such as user name and password). The client can then access the resources on behalf of the resource owner.

To allow access to the resources, the OAuth 2.0 client and the authorization server interact to authenticate the resource owner and delegate the necessary authorizations to the OAuth 2.0 client within the authorization code flow.

Figure 1: OAuth 2.0 Grant Type: Authorization Code

  1. The resource owner makes a call to protected resources using the OAuth 2.0 client.

  2. The OAuth 2.0 client has no access token for the target system and redirects the browser to the authorization endpoint of the authorization server. This redirection is called authorization code request. At the authorization server, the resource owner is authenticated and can further restrict access or simply grant access to the preselected scopes.

  3. The authorization server sends the authorization code back to the OAuth 2.0 client by redirecting the resource owner's user agent back to the redirection URI (that was defined during OAuth 2.0 client registration).

  4. The OAuth 2.0 client sends an access token request to the authorization server's token endpoint. This access token request contains the authorization code.

  5. The authorization server receives the access token request at its token endpoint and validates the authorization code. After a successful validation, the authorization server returns an access token to the OAuth 2.0 client.

  6. The OAuth 2.0 client uses the access token to request resources.

  7. The resource server grants the OAuth 2.0 client access to protected resources in accordance with the access token.

Result

Using the OAuth 2.0 client, you do not need to share credentials and you can access permitted resources with restricted authorizations.

More Information