4 ms·

This is more OAuth's mistake than Grammarly's. OAuth is frankly one of the very worst specs that I've tried to learn. Not just in the conceptual flaw of having

This is more OAuth's mistake than Grammarly's. OAuth is frankly one of the very worst specs that I've tried to learn. Not just in the conceptual flaw of having so many types of flows (each with their own caveats), but in the opacity of the documentation (why use words like resource-owner/client/resource-server/authorization-server when user/browser/server/third-party would be more precise and reduce the learning curve), the reliance on the user to learn nearly the entirety of the spec just to use it properly (the main red flag of any framework or standard), and the way it ignores how it might be compromised in the implicit flow or via untrusted Javascript running in <script> tags (in fairness that makes most SPA grants security theater). All of this to replace the easily understandable concept of, say, a browser's session cookie. I feel that there's too much wrong with OAuth to be fixed, that any new spec derived from it will also be terrible, and that any design-by-committee substitute will be just as bad. Leaving me no choice but to give OAuth a vote of no confidence. Kind of ok but still terrible documentation: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2 https://www.digitalocean.com/community/tutorials/an-introduc... You call this documentation? https://auth0.com/docs/get-started/authentication-and-authorization-flow https://auth0.com/docs/get-started/authentication-and-author... A good replacement would handle all use cases without leaking any details about the implementation. Loosely that would look like the standard way of obtaining a security key and/or secret from the third party social provider and storing it in the backend server to access user details, filtered by whatever details the user chooses to share from the third party. If an SPA wants to be serverless, then a similar process must happen within, say, a P2P virtual server running a consensus algorithm like Raft or maybe borrowing blockchain concepts. IMHO this last part is still an open problem involving circles of trust, and is what has put this complexity on the shoulders of developers since roughly the mobile/social revolution that happened around 2007. All serverless stuff is either pretend (AWS Lambda) or a pipe dream without real P2P. I also feel comfortable blaming OAuth for any factual mistakes I just made writing this.

paulddraper 3y ago
https://oauth.net/2.1/ https://oauth.net/2.1/ > OAuth 2.1 is an in-progress effort to consolidate and simplify the most commonly used features of OAuth 2.0.
- zackmorris 3y ago
  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.
deleted 3y ago
[deleted]

paulddraper 3y ago

https://oauth.net/2.1/ https://oauth.net/2.1/ > OAuth 2.1 is an in-progress effort to consolidate and simplify the most commonly used features of OAuth 2.0.

zackmorris 3y ago
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.

deleted 3y ago

[deleted]