Consider requiring PKCE

[michielbdejong]

There seems to be some progress in general opinion about implicit grant flow best practices, where probably we should require https://www.oauth.com/oauth2-servers/pkce/ in how the remoteStorage spec uses OAuth Implicit Grant.

https://tools.ietf.org/id/draft-parecki-oauth-browser-based-apps-02.txt
https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926
https://www.google.com/search?q=implicit+flow+problems

[raucao]

Just completing the links: the current draft of the BCP can be found at https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ (moved to a new name)

[michielbdejong]

cc @fkooman

Yeah, it would be best to switch to authorization code profile and use PKCE. That's what I've been doing for other projects, i.e. support RFC8252 "OAuth 2.0 for Native Apps". This draft @skddc refers to is very similar.

Specifically relevant for RS: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-03#section-6.3

[raucao]

This draft mentions requirements for keeping implicit grant flow (but generally recommends not using it anymore): https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15

[raucao]

@michielbdejong and I have discussed this topic today, in combination with #187. We have come up with a plan for both the long-term PKCE transition as well as short- and long-term versioning:

Step 1

• Split official protocol versioning from draft versioning, and publish the next draft as remoteStorage version 1.0
• Add PKCE as optional addition for both clients and servers in 1.0 (servers are still required to support Implicit Flow)
• Breaking changes now require RS protocol version updates from 1.0, but new drafts without breaking changes do not (although they may do minor version upgrades for big new features)
• Adapt the current version management in rs.js; make it refuse connections and inform the user about incompatible servers if the server's version is not a draft-XX version and higher than 1.x (which is not the case for any servers until RS 2.0 is published).

Step 2

Once most of the known clients/apps have added support for PKCE, we can prepare for publishing remoteStorage 2.0, which would require PKCE. Since this is a breaking change, any other breaking changes not included in 1.0 would also be on the agenda for potential inclusion in that version then. The draft spec may or may not be submitted as an RFC before then, i.e. RS 2.0 work may happen in a new draft later.

Implementation

Since there was a new draft version published a bit prematurely today (it didn't include the 2 latest PRs), we will make these changes soon and break out of the 6-month draft update cycle (at least for this one). Client and server devs can then start implementing PKCE as an optional feature.

Feedback welcome.

[elee1766]

@raucao hi! first of all, thank you for all the work on remotestorage. this is a really cool project and i see so much value in it.

i was curious what would you say the time line on the migration to version 2.0 is?

the reason i am asking is because i would really like to finalize the golang remote storage client and server library i am working on (along with a proof of concept implementation which uses the library) https://gitlab.com/tuxpaint/remotestorage

i encountered an issue when i actually tried using it, as most modern OIDC providers actually do not support implicit grant at all, and require PKCE.

I'm wondering also what your advice for me might be - should i just try to implement the up-in-the-air remoteStorage 2.0 with PKCE in this library for now?

[raucao]

Hey @elee1766, great to hear about your work on a Go implementation, and even for both client and server!

If you want your implementation to be used by anything in the real world and in the foreseeable future, it will have to be RS 1.0, since 2.0 is only a long-term future plan, and we need to get everyone migrated to 1.0 with PKCE first.

Personally, I would recommend to start with the current spec and then add PKCE as soon as the reference client supports it (or has a working PR for it at least).

What is the relevance of OIDC providers to your implementation, if I may ask?

[elee1766]

@raucao i want to be able to delegate authentication of the remotestorage to a self hosted oidc provider (zitadel, pocketid) so that i can create a server implementation that does not involve user authentication and management, as that is a separate problem.

so far it seems the easiest way to create a proper remotestorage 1.0 server is to have to do the user management and authentication myself?

maybe im doing something all wrong though.

[DougReeder]

Any RS server must return Webfinger data, but I believe the data can contain URLs from other sites, so I'd guess that's possible. I don't know of any worked examples, though.

https://github.com/remotestorage/armadietto/blob/master/lib/routes/webfinger.js

[elee1766]

@DougReeder yes thats what i have been playing around with.

my goal is to be able to set the discovery url and the necessary client_id and secret, specify the claims, and have things sort of work from there: https://gitlab.com/tuxpaint/remotestorage/-/blob/master/cmd/myrs/main.go?ref_type=heads#L28

(myrs is the hobby implementation to test the server library)

[raucao]

Serving Webfinger records is required for the user address domain, but the RS server implementation can get away with delegating this, too.

Delegating auth entirely requires that you can still verify arbitrary access scopes, and yes, the provider would have to support Implicit Grant flow for the foreseeable future. You could try to split up the responsibilities and only do authentication, i.e. login, via the OpenID Connect provider, but then do the actual RS authorization in your implementation.

This way, you wouldn't have to worry about any OpenID Connect providers having to be directly compatible with remoteStorage. But you would obviously need some kind of UI for managing connected apps for the user. However, some kind of app dashboard showing connected apps is usually a nice thing to have anyway.

[elee1766]

but then do the actual RS authorization in your implementation.

But you would obviously need some kind of UI for managing connected apps for the user. However, some kind of app dashboard showing connected apps is usually a nice thing to have anyway.

yeah. this is sort of what i decided to try to do. just specify the authorization for now in a config file and do the authentication with the delegated provider.

i currently am maintaining a self-hosted paste server: https://gitlab.com/tuxpaint/gopaste and want to stop, and just use my own remotestorage client with a remotestorage server instead.