So I have been reading RFCs today...because quarantine and I am actually attempting to understand what "the standard" is. I think the best documents are currently OAuth 2.0 for Browser-Based Apps and Proof Key for Code Exchange by OAuth Public Clients. The interesting part (section 6) in the best practices document (1st link) there is great discussion about choosing an OAuth2 solution based off the architecture you're working with, which makes a lot of sense. Unlocking this critical aspect essentially answered some of my questions.
The most important being to realize that if your architecture and requirements don't "need" redirects then there is probably a more secure way to accomplish the task without PKCE, essentially that PKCE would be a less secure option if one can get it done without needing redirects. Maybe that was super obvious but I was just assuming that PKCE is the new standard so everyone needs to switch to it which was causing me to try to jam all the concepts together.
2) Regarding User Registration. Based off the above logic an application that also worries about initial user registration probably is in a position architecturally to not need PKCE so it is out of bounds.
3) Regarding Refresh Tokens and PKCE. If one is truly working with a public client (that you really need PKCE) it is the case that issuing refresh tokens is indeed more risk than the access token. In my opinion the separate time expiry you suggested would not increase security, but there are some interesting suggestions for refresh tokens with PKCE in the best practices, including not using them, or using a decreasing expiration refresh token that still needs to be reacquired every 24 hours.
So I have been reading RFCs today...because quarantine and I am actually attempting to understand what "the standard" is. I think the best documents are currently OAuth 2.0 for Browser-Based Apps and Proof Key for Code Exchange by OAuth Public Clients. The interesting part (section 6) in the best practices document (1st link) there is great discussion about choosing an OAuth2 solution based off the architecture you're working with, which makes a lot of sense. Unlocking this critical aspect essentially answered some of my questions.
The most important being to realize that if your architecture and requirements don't "need" redirects then there is probably a more secure way to accomplish the task without PKCE, essentially that PKCE would be a less secure option if one can get it done without needing redirects. Maybe that was super obvious but I was just assuming that PKCE is the new standard so everyone needs to switch to it which was causing me to try to jam all the concepts together.
1) Regarding Storing Tokens. I think you were very close (if not 100%) to what is suggested in the best practices with your previous post Secure authentication in Nuxt SPA with Laravel as back-end
2) Regarding User Registration. Based off the above logic an application that also worries about initial user registration probably is in a position architecturally to not need PKCE so it is out of bounds.
3) Regarding Refresh Tokens and PKCE. If one is truly working with a public client (that you really need PKCE) it is the case that issuing refresh tokens is indeed more risk than the access token. In my opinion the separate time expiry you suggested would not increase security, but there are some interesting suggestions for refresh tokens with PKCE in the best practices, including not using them, or using a decreasing expiration refresh token that still needs to be reacquired every 24 hours.
Yes, the part with decreasing the
refresh_tokenexpiration time is very interesting, and I might try that.