Hello, author here. First off, thank you for taking the time to read this.

The original draft started out much more technical than this version, but it was simplified to read less like a whitepaper. In the original draft, I discussed the Authorization Code Grant with the PKCE extension, which is for public clients (clients that cannot be trusted):

  "The barebones authorization code grant is used for server-side applications, where confidential clients are trusted with a secret. By using the PKCE (Proof Key for Code Exchange) extension, this same flow can be used with public clients like browsers or mobile applications. The only modification to this flow is cryptography.

  1. Client generates a random string of length 43-128 characters and turns it into a URL-safe 256 hash. Other hashing methods can be used

  2. Client directs the resource owner to sign into the authorization server. The hashed string is included as a parameter in the query

  3. Resource owner signs in and approves client, then redirects back

  4. Client makes an HTTPS POST request for a token. Included is the unhashed randomly generated string

  5. Authorization server hashes this string with the same hashing method (SHA256) and compares its calculated hash to the hash received in step 2. If the hashes match, and access token is issued

  The trick here is knowing that the odds of two hashes with different inputs being the same are infinitesimally small and can be ignored. If even one character is different in the input, the outputted hash will be entirely different. By sending the hash in step 2 and then the original input string in step 4, the authorization server can verify it is still communicating with the authorized client by comparing what it received to what it produced. Any fraudulent client would have no way of knowing what the input string is."