-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move from Implicit Grant to PKCE #170
Comments
Sounds like things have moved on in OAuth land! :) I didn't know about PKCE yet, interesting. @fkooman what do you think? We would need to try this out to know what it would look like on the server-side and in remotestorage-js,not sure if we want to do this in version 12 or leave it for version 13, to give people some more time to adapt. |
PKCE only makes sense when using "authorization code" flow. So, two things should happen before you can use PKCE:
Implementing the "authorization code" flow for in-browser only OAuth is not trivial. The flow requires additional back-channel calls (XHR?) from the browser to the OAuth server to exchange the authorization code, obtained at the redirect URI in a query parameter, for the access_token using a HTTP (form) POST to the token endpoint. This may or may not require additional CORS headers. I haven't looked at JS OAuth for a long time, so I'm not sure if ready-to-use OAuth libraries are available for use with the authorization code flow when operating only in the browser... I'm not even sure it can work! |
BTW (just an FYI), the IndieWeb folks recently came to the same conclusion as you guys did for RS in regards to OAuth: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web |
I was looking into adding Nextcloud as a server. However when reading your RFC I noticed you use Implicit Grant. The OAuth2 security best practice recommends not to use Implicit grant. You should switch to PKCE instead.
The text was updated successfully, but these errors were encountered: