search

jebrosen / rocket_oauth2

OAuth2 for Rocket applications
Apache License 2.0
68 stars 27 forks source link

Support for PKCE #58

Open emirror-de opened 3 weeks ago

emirror-de commented 3 weeks ago

I am trying to use this library in combination with kanidm, but it requires PKCE.

Is support for PKCE planned in the near future? I would be happy to help implementing if desired.

Additional info: https://www.oauth.com/oauth2-servers/pkce/

jebrosen commented 2 weeks ago

So a while back (probably months or years?) I had actually started investigating PKCE and concluded that it was usually not relevant for servers using rocket_oauth2: PKCE primarily protects against a malicious application that is able to observe ("intercept") responses from and requests to the authorization server (including the authorization code). In the context of a desktop or mobile application, the redirect URI (often a custom URI scheme) can be registered by the malicious application to perform this interception so this is a pretty identifiable weak point.

But in the context of the web client/server model rocket_oauth2 is typically used with, the malicious application would need to be running on the same machine as the rocket_oauth2 server to intercept the particular code -- which is typically more difficult to pull off than a custom URI scheme registration, and much more catastrophic in other ways.

As I understand things today, the recommendation is to use PKCE "everywhere" (for additional reasons) and I do think it's worth supporting. That said I don't actively maintain this library at present -- so I'd be happy to integrate a working implementation, or if it's small I might get around to it some time. One particular obstacle I remember, and one reason I didn't implement it before, was the requirement for some storage to associate the challenge to the code across requests. If that's doable with a secure Cookie that would probably be best -- otherwise, this will require some kind of persistent storage or cache and APIs to configure them. I considered in-memory but that's a no-go for multi-instance deployments - either the storage needs to be shared across all instances, or the traffic has to be pinned such that the same client always reaches the same instance.

emirror-de commented 2 weeks ago

Yes, I agree to your thinking. Going for the secure cookie sounds reasonable to me as well. I have no experience with pinning the network traffic yet, but it sounds way more complicated and error prone than solving it with a cookie. I will give it a try this week.