Dual authentication (from cookie and token) issues in production environments

[sneridagh]

Given an app completelly independent from Plone (and not served by Plone), that shares the same server name, but served from another path. The app is using token authentication from the plone.restapi PAS plugin.

We are experiencing issues since the cookies are leaking from Plone (if you are authenticated) to the other app. This causes authentication inconsistencies when querying plone.restapi endpoints, for example, when logging out the app (you are still logged in Plone), or if the token expires (most likely before the cookie does).

Could we find a way to mark how the authentication has been granted? Something like marking the response with a header (that later, could be checked by the app), let's say: X-Auth-Via: cookie/token ? Or just other approach to prevent this happen?

/cc @bloodbare @tisto @buchi @lukasgraf

[tisto]

@sneridagh everybody who works with plone.restap runs into that issue. We should really try to fix it. What if we would just prevent a zope-only user to authenticate with plone.restapi alltogether? We could send back a meaningful error message to explain why the authentication was rejected. This is better then letting people run into meaningless error messages.

[tisto]

This is constantly causing troubles when using plone.restapi in production. I think we should just prevent the admin user to log into plone.restapi altogether. @sneridagh @jaroel @csenger @buchi @lukasgraf opinions?

[lukasgraf]

@tisto I was thinking about this recently: At the Beethoven Sprint we briefly discussed the CSRF story, and whether we might be able to disable CSRF protection for plone.restapi services alltogether. If I remember correctly, this was more or less how this discussion went:

• CSRF is only an issue if session-based authentication schemes are in play (like cookie based auth, or HTTP basic auth)
• If we were to
  • Always require JWT auth for API endpoints
  • ensure the jwt_plugin is at the top the list of Authenticator plugins
  • and strip any session based authentication (basic auth header, cookies) from the request in the jwt_plugin (only after successful auth via JWT)

we should be safe to disable CSRF protection for plone.restapi endpoints.

If we were to implement that, I think this would also pretty much solve this double-authentication issue as a side-effect. @vangheem did I summarize this correctly?

[sneridagh]

I think that #412 won't fix this. I reopened it to test it again. cc/ @buchi @tisto

However, the comments diverged the original problem to the Zope user one (which #412 already solved).

Bottom line is that given a browser and a previous cookie auth happened in a Plone site, when the browser access to an REST API enabled app and sends the cookie too (because, let's say the app and the plone site lives under the same domain) then the REST API authorization is happening (without token) because of the original cookie, not because of the token.