Hello,
Let's break down the situation and explore possible explanations.

Understanding PKCE and the Code Challenge/Verifier

PKCE (Proof Key for Code Exchange) is designed to prevent authorization code injection attacks.
The client generates a code_verifier (a high-entropy random string).
The client transforms the code_verifier into a code_challenge (usually by hashing it).
The client sends the code_challenge with the authorization request.
The authorization server stores the code_challenge.
When the client requests an access token, it sends the code_verifier.
The authorization server recalculates the code_challenge from the received code_verifier and compares it to the stored code_challenge. If they match, the server issues the token.
The Discrepancy

You're correct:

The primary security check (verifying the code_verifier) should be done by the authorization server (Airtable's backend).
The documentation states that the client should verify the returned code_challenge, which seems redundant.
The provided example code does not perform this check.
Possible Explanations

Defense in Depth:
While the server's verification is crucial, the client-side check could be considered a "defense in depth" measure.
It could protect against scenarios where the authorization response is somehow tampered with after the server has validated the code_verifier but before the client receives it.
However, this is highly unlikely, and HTTPS should provide adequate protection against this.
Documentation Error/Oversight:
It's possible that the documentation is simply incorrect or outdated.
The emphasis might be on the general principle of validating inputs, but the specific mention of the code_challenge might be misplaced.
The fact that the official example does not implement this check lends much weight to this possibility.
Edge Cases/Internal Requirements:
There might be specific edge cases or internal requirements that Airtable has that aren't explicitly documented.
Perhaps they've encountered rare scenarios where this client-side check has proven useful.
This is the least likely scenario, as if they had a good reason, they would have likely provided better documentation.
Early Implementation Artifact:
It is possible that the check was required in early versions of their OAuth implementation, and that the documentation was not updated when the implementation was refined.
Why the Example Doesn't Check

The fact that the official Airtable example doesn't perform this check strongly suggests that it's not a necessary step. If it were crucial, they would have included it in their example.

Recommendations

Prioritize Server-Side Verification: Focus on ensuring that Airtable's backend is correctly validating the code_verifier. This is the core security mechanism of PKCE.
Consider the Risk vs. Effort: Implementing the client-side code_challenge check adds complexity for minimal security benefit.
Follow the Example: If the official Airtable example doesn't perform the check, it's likely safe to omit it.
Reach Out to Airtable Support: If you have concerns, consider contacting Airtable's support team to clarify the documentation. They can provide definitive guidance.

E-ZPassMD

Hey there,

I don’t see the text you quoted in Airtable’s OAuth Specs. Do you think that has been removed and it was a mistake?

I’m trying to implement the OAuth flow myself.

Thank you!