Instead of requesting authorization directly from the resource owner (resource owner's credentials), in this grant type, the client directs the resource owner to an authorization server. The authorization server works as an intermediary between the client and resource owner to issues an authorization code, authenticate the resource owner and obtain authorization. As this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a Web browser) and receiving incoming requests (via redirection) from the authorization server.
The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint (you can use the
/authorize endpoint for the authorization code grant type of OAuth 2.0). It includes the client identifier, response_type, requested scope, and a redirection URI to which the authorization server sends the user-agent back after granting access. The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner granted or denied the client's access request. Assuming the resource owner grants access, the authorization server then redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes an authorization code.
The client then requests an access token from the authorization server's
/token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. It then includes the redirection URI used to obtain the authorization code for verification. The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI matches the URI used to redirect the client from the /authorize endpoint in the previous response. If valid, the authorization server responds back with an access token and, optionally, a refresh token.
Invoking the Token API to generate tokens
Assuming that both the client and the API Gateway are run on the same server, the Authorization API URL is
- query component:
For example, the client directs the user-agent to make the following HTTP request using TLS.
The authorization server redirects the user-agent by sending the following HTTP response:
Now the client makes the following HTTP request using TLS to the
/token endpoint responds in the same way like in password grant type.
Note that if you are using a separate server for authentication (e.g., a distributed API Manager setup or an instance of WSO2 Identity Server as the authentication server), be sure to give the full URL of the authentication server in the
<APIM_HOME>/repository/conf/identity/application-authentication.xml file. The default configuration has a relative path, which works in a standalone API Manager setup:
To enable Authorization Grant and Implicit Grant through the management console, you have to add a Callback URL when the application is created. A Callback URL is a redirection URI in the client application which is used by the authorization server to send the client's user-agent (usually web browser) back after granting access.