Thank you for the excellent tutorial. This is the best tutorial I have found of using Passports PKCE functionality and I would have not been able to figure it out myself. I was able to port your solution today into a React front-end with Laravel back-end.
I just have a few questions about using this technique if you have time.
1) If the OAuth2 server knows when the access token expires and therefore won't allow access of an expired token, it seems that its fine to store the access token not in a cookie since our main protection is the quick timeout? (I'm planning on using Redux which is basically session)
2) Does a registration page necessarily now need to send a user to the PKCE flow after registration rather than issue a token using password grant on initial registration?
3) Does PKCE matter for the refresh token exchange? As in, after we have gone to all this trouble to get the access token through PKCE do we shoot ourselves in the foot if we are not using the same precaution on a subsequent refresh token?
I'm always storing my short-lived access_token in the cookie, and my long-lived refresh_token in the httponly cookie, also Laravel has a CSRF protection out of the box. That way I'm protected from potential XSS and CSRF attacks.
I think you must use the PKCE flow, because the client_ids are not the same. But I've never tested this, maybe you could try it out and comment here if you could make it work.
No, we are having a separate route in which we're refreshing out token. My refresh_tokens expiry time is 10 days, but the user refresh_token is newing up every time new access_token is requested. So the user will have to go through the whole PKCE flow if they weren't active for 10 days straight.
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.
Thank you for the excellent tutorial. This is the best tutorial I have found of using Passports PKCE functionality and I would have not been able to figure it out myself. I was able to port your solution today into a React front-end with Laravel back-end.
I just have a few questions about using this technique if you have time.
1) If the OAuth2 server knows when the access token expires and therefore won't allow access of an expired token, it seems that its fine to store the access token not in a cookie since our main protection is the quick timeout? (I'm planning on using Redux which is basically session)
2) Does a registration page necessarily now need to send a user to the PKCE flow after registration rather than issue a token using password grant on initial registration?
3) Does PKCE matter for the refresh token exchange? As in, after we have gone to all this trouble to get the access token through PKCE do we shoot ourselves in the foot if we are not using the same precaution on a subsequent refresh token?
I'm always storing my short-lived
access_tokenin the cookie, and my long-livedrefresh_tokenin thehttponlycookie, also Laravel has a CSRF protection out of the box. That way I'm protected from potential XSS and CSRF attacks.I think you must use the PKCE flow, because the
client_ids are not the same. But I've never tested this, maybe you could try it out and comment here if you could make it work.No, we are having a separate route in which we're refreshing out token. My
refresh_tokens expiry time is 10 days, but the userrefresh_tokenis newing up every time newaccess_tokenis requested. So the user will have to go through the whole PKCE flow if they weren't active for 10 days straight.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.