Cloud Application Integration (On-Premises) : Administering Integration Server : Configuring OAuth : Authorization Grant Types Supported by Integration Server : Authorization Code Grant
Authorization Code Grant
The authorization code grant type is used to authenticate and provide access to clients that have credentials on the authorization server. This grant type requires the client to authenticate to the authorization server before obtaining an access token.
You use the authorization code grant type to authenticate and provide access to confidential clients. A confidential client is a client that supplies a client ID and client secret to the authorization server in order to obtain an access token. Confidential clients correspond to an account on the authorization server. If a client does not have the proper credentials (client ID and secret) for the user account, the authorization server does not grant the client an access token. To specify a confidential client in Integration Server Administrator, set Type to Confidential. For more information, see Registering Clients.
When using the authorization code grant type, the authorization server can issue a refresh token to the client application along with the access token. A refresh token enables clients to get a new access token without requesting additional approval from the resource owner. When the access token expires, the client application can use the pub.oauth:refreshAccessToken service to pass the refresh token to the authorization server to request a new access token.
The following diagram illustrates how the Integration Server authorization server participates in the authorization code grant process.
Authorization Code Grant Flow
Stage
Description
1
The client application initiates the process by calling the pub.oauth:authorize service to request access to the resource owner’s data.
2
The pub.oauth:authorize service validates the request. If valid, the service responds with an HTML page that informs the resource owner that the client application is requesting access within a specified scope. The resource owner uses the HTML page to approve or deny the request.
3
When the resource owner approves the request, the approval page invokes an internal service on Integration Server. If the resource owner denies the request, an error is returned.
4
Integration Server generates an authorization code for the client application. The server uses HTTP redirection to instruct the resource owner's browser to transmit the authorization code to the redirection URI provided by the client application.
5
The service at the client application’s redirection URI passes the authorization code to the pub.oauth:getAccessToken service on Integration Server to exchange the authorization code for an access token.
6
Integration Server issues an access token to the client application. If set to do so, the authorization server also issues a refresh token to the client.
7
The client application uses the access token to execute a service on the resource server.
8
The resource server checks with the authorization server to make sure the requested service is within the scope for which the access token was issued and whether the client is authorized to access the folders and services in the scope.
Copyright © 2015- 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback