Software AG Products 10.11 | Running Business Processes and Composite Applications | webMethods Integration Server Administrator’s Guide | Configuring OAuth | Authorization Grant Types Supported by Integration Server | Authorization Code Grant
 
Authorization Code Grant
 
Using PKCE with the 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 and public 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:getToken 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
Activity flow for authorization code grant type
The following table describes each step in the 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.
If PKCE is required for public clients, the client must create a code_verifier value. The client must pass the following additional values to the pub.oauth:authorize service:
*code_challenge, which is a transformation of the code_verifier value.
*code_challenge_method, which is the transformation method for the code_verifier.
For more information about PKCE, see Using PKCE with the Authorization Code Grant.
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.
Integration Server saves the supplied code_challenge and code_challenge_method values in the OAuthPKCE cache.
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:getToken service on Integration Server to exchange the authorization code for an access token. Integration Server also ensures that the client is allowed to use the authorization code grant.
If PKCE is in use, the client must also supply the code_verifier value to pub.oauth:getToken.
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.
If PKCE is in use, Integration Server applies the code_challenge_method to the supplied code_verifier. If it matches the code_challenge provided in Stage 1, Integration Server issues an access token.
7
The client application uses the access token to request a resource on the resource server.
8
The resource server checks with authorization server to make sure the access token is valid. If it is, the resource server checks that the requested service is within the scope for which the access token was issued. It also checks that the resource owner is authorized to access the requested resource.