-
Notifications
You must be signed in to change notification settings - Fork 113
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
Accept reva token as a bearer authentication #3315
Conversation
Let me please throw in my 2 cents. I see some security aspects in this PR. Reva access tokens are very powerful. Most of them are not scoped and could allow access to any resource and all file operations. IMHO it is not a good practise to use reva access tokens outside of reva and on the client side. Clients should only use short-living OIDC tokens. This is how we do that in the ocis middlewares. |
Let me explain that a bit better: As long as you use the reva-CLI or another CERN internal client, this not an issue. BUT: We are currently sending Reva Tokens via the cs3org Wopi server to the Microsoft Office365 Server. Now the office 365 Server has a valid working reva jwt token. That means it can have access to all the files of a specific user as long as the application has direct access to the reva gateway. (which is not the case when it is not directly exposed) Enabling that access also via HTTP is like opening the gates. |
@labkode It seems that we have a little disconnect how to handle authentication in reva. Maybe let us move that discussion to direct communication. |
I think the problem is more to restrict the scope of the token we are sending to Microsoft to only the resource the app will be using. |
I think there are two issues with reva tokens currently:
|
Yes, or better encrypt them. It is always best practise that any 3rd party which does not need credentials should not get those. see cs3org/wopiserver#90 |
d03b9e7
to
b351fe4
Compare
Hi @micbar, The issue today is that we give full scope when passing the token for another purposes (like WOPI or OCM), this obviously needs to be fixed, what @gmgigi96 said. Today the token we use is the one we get from our IDP, and that is a general token for every service, which has a few issues for us today: they are very short lived and web does not handle them like it should (owncloud/web#7729), giving the user a very bad UX. We also force users to use 2FA, so asking them to login more than once in a day is painful. Today, for every request that arrives to Reva, we issue a query to verify the token against our IDP. To provide the best usability to the users (like Google and co do), we'll use longer tokens, up to a full working week. This direction also align us with the support for application passwords that will be needed by the sync client, we won't be asking the user to login in the sync client every now and then, the token set on the client must be permanent (this is also the direction that other companies are doing to use 3rd party applications). I hope this clarifies a bit the intention here. |
No description provided.