Thanks! After studying OAuth 2.1, I think that the code challenge of the Proof Key for Code Exchange (PKCE/pixy) may fulfill what the Raft/blockchain/P2P concep

Thanks! After studying OAuth 2.1, I think that the code challenge of the Proof Key for Code Exchange (PKCE/pixy) may fulfill what the Raft/blockchain/P2P concept I mentioned would do: https://developers.onelogin.com/openid-connect/guides/auth-flow-pkce https://developers.onelogin.com/openid-connect/guides/auth-f... https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce https://auth0.com/docs/get-started/authentication-and-author... https://oauth.net/2/pkce/ https://oauth.net/2/pkce/ Unfortunately, I can tell that the people who write these articles don't actually know how the flows work at a deep enough level to speak about security ramifications. My mind immediately jumps to edge cases which aren't discussed, like this: https://stackoverflow.com/questions/75341865/oauth-authorization-code-flow-with-pkce-on-stateless-backend https://stackoverflow.com/questions/75341865/oauth-authoriza... The whole point of PKCE is to allow a SPA/mobile/serverless app to obtain an access token without a client secret (since that could be leaked from Javascript or the device's filesystem). But none of the tutorials explain how to use PKCE with a SPA and custom API server written in something like PHP, against a third party access token provider like Google. To me, if OAuth authentication happens through the API server, then the user has to trust that the API server acting on their behalf won't steal their data from the third party. In an ideal world, I guess that the browser/device would perform all communication with Google and forward that response data to the API server. But in practice, API servers usually facilitate OAuth flows to third parties, which leads to stuff like surveillance capitalism. I don't expect to ever understand this at a deeper level, so will have to trust that whatever OAuth SDK I'm using is secure for PKCE. Including stuff like storing any tokens/codes as encrypted in any databases. I still can't shake the feeling that trusting OAuth involves drinking the kool-aid at some level. TL;DR: OAuth with a custom API server acting on the user's behalf to communicate with a third party is no different than Mint being able to log into your bank account, so it's up to the API server to maintain good security standards. Unless OAuth happens entirely in the frontend app and it just forwards any third party data to the API server (which is rarely done), which still opens the user up to exploits in Javascript or the device's filesystem.