What is Proof Key for Code Exchange (PKCE) and does my integration require it?

All users of AWeber’s API must authenticate their requests using OAuth. The standard OAuth 2 flow we describe in our documentation assumes you can keep both the client ID and client secret hidden and protected. Some kinds of integrations such as mobile apps or WordPress plugins may not be able to do this because the code and configuration is available publicly and there can be no guarantee that keys included with the code can be kept secret. For these situations there is a variant flow for OAuth 2 called Proof Key for Code Exchange, abbreviated PKCE. AWeber refers to integrations using this alternative flow as public clients.

If you have a public client type integration, you will not see a client secret next to your app name in your developer account. Instead you will only see a client ID.

Rather than using the client secret during the OAuth flow, PKCE uses a code challenge and verifier. The verifier is simply a random string of ASCII characters. A hashed version of this string (called a code challenge) is sent to AWeber instead of the client secret when the authorization code is requested. Later when the token exchange happens the unhashed verifier is sent instead. If AWeber’s servers can hash the verifier and come up with the same challenge that was sent previously the request is considered valid. For full details on how to use the PKCE variant of OAuth 2, please see our instructions.

Do I need to use PKCE?

We briefly discuss which integrations should use the public OAuth 2 flow in our documentation’s “Public or Confidential” section, but if you cannot be reasonably certain that your client secret will remain confidential you should use PKCE. Even if using HTTPS there are other ways your secret could become public. HTTPS is an excellent way to protect your integration, but it’s not enough to use HTTPS alone as it’s possible to decrypt HTTPS requests. Other reasons the secret could be made public include code being packaged and shipped to third parties via a store of some kind or being posted in an open source repository without the configuration being separated. This includes all WordPress plugins and mobile apps.

The official specification for PKCE, RFC 7636, discusses how the attack against the standard OAuth 2 flow works and how PKCE can mitigate the issue. This may be helpful to you in determining if you need to use the public flow provided for AWeber’s API. If you’re not sure or cannot decide which client type is better for your integration reach out to us at api@aweber.com and we’d be happy to help you decide.