ACP authorization code grant flow with PKCE
Learn what an authorization code grant with the Proof Key of Code Exchange is and what its process is. Find out which applications can use the authorization code grant flow with PKCE in a safe and secure manner.
Authorization code grant flow with PKCE in a nutshell
Authorization code grant with the Proof Key of Code Exchange (PKCE) is an extension of the standard authorization code grant OAuth flow. It is designed to be a secure substitute for the implicit flow for single page applications (SPA) or native applications.
To learn more about PKCE, see the RFC7636 PKCE OAuth specification.
Authorization code grant with PKCE in depth
Both SPAs and native applications are considered to be public clients. It means that they are not able to securely store client secrets in their code. Single page apps have their entire source code available in the browser. Native applications can be decompiled and the client secret that is available for all of the application’s users and devices becomes exposed as a result.
To use the ACP authorization code grant flow type, the client must match the following criteria:
It must be able to interact with the resource owner’s user-agent, for example, a web browser.
It must be capable of receiving incoming requests (via redirection) from the authorization server.
Grant flow diagram
Authorization code grant with PKCE process
The authorization code grant with PKCE flow is very similar to a standard authorization code grant flow. The difference lies in the process of client authentication. To learn more about it, see the Client authentication set to none and with the use of PKCE documentation.
A user tries to access the application (the client).
The client redirects the user to the authorize endpoint.
The client must inform ACP of its desired grant type by using the
response_typeparameter. For the authorization code grant flow type, the value of the
response_typeparameter must be
ACP authenticates the user and displays a consent screen if there is an authorization scope to be granted.
ACP does not display the consent screen when there is no authorization scope to be granted.
The user gives their consent.
ACP issues an authorization code.
After ACP generates the authorization code, it is redirected to the redirection endpoint configured for the registered client. The client must have at least one registered redirection URI. If there are multiple registered redirection URIs, the request to the
authorizeendpoint must always include the
redirect_uriparameter. If there is only one registered redirection URI for the client, it does not have to include the
redirect_uriparameter in the request to the
The client requests authentication to the token endpoint using authorization code provided in the previous step.
To learn more about token endpoint authentication methods, see the client authentication documentation.
ACP validates the request.
ACP returns the token.
The client requests protected resources from the resource server and submits the token it received in the previous step.
The resource server validates the token and responds the requested resources.
Cloudentity Auth JS