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."Passwords would be leaked all over the place (verbose logging, debugging to investigate issues, etc...). That's totally compromising employees/users, as passwords are rarely changed and reused for personal accounts.
Every other API gets a short lived access token. While that also needs to be secure, the vulnerabilities of that become different. Eg if your logs printed your access tokens, and after 30 days you moved them to S3, no one could read the S3 logs and log into your service. Probably a terribly insecure example but i think it illustrates the different vectors to be concerned about. Refresh tokens vs Access tokens just have different surface areas to be concerned about.
If the service handling your access token has some security issues (old version of x y z, etc) there is limited damage if nefarious actors acquire that token. They could not keep your session alive, spread horizontally, etc. Also, you can make access tokens very short lived to minimize the window of opportunity, should someone acquire one.
Then I can concentrate on my "session service" (the thing issuing tokens) to be very secure, and tune the characteristics of either token as needed.
I have been trying to comprehend and formulate the main idea behind the usage of this technology, for example, as follows:
Why it is the central idea? Because we do not consider where and how the tokens are obtained: you can get it by USB stick or maybe forge somehow artificially. It is important only that access to resources requires a special piece of data rather than (traditional) credentials. The main question for the client is whether the server will accept this token or not. For the server, the main question is whether it can trust this client and its tokens.We aslo abstract from what is inside this token and how the server decides what to do - these are considered details.Do I miss something more important?