-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
OAuth 2.0 support for ownCloud [$5] #10400
Comments
also some other folks that might be interested in this: |
The |
I love this! Already added it to the »Integration Efforts« section on https://github.com/owncloud/core/wiki/Apps#integration-efforts This is especially interesting for the 3rdparty mobile and desktop apps as well. cc @davivel @phedlund @David-Development @Leandros @maltefiala |
Sounds amazing! |
This seems really, realy cool. A couple of things I miss:
|
I'm planning to support both.
Yep. There are also some other important things that aren't set yet. Once we got a decision for what release this will be scheduled this I'll create a throughout documentation with examples (similar to https://developer.github.com/v3/oauth/) to make sure that the implementation will actually be used :-) |
This is a long-awaited addition to owncloud. Huge leap forward when this is implemented for third-party apps. |
The proposal as discussed on irc is code wise too complicated for app devs. More discussion will follow at the conference :) |
From what I understand, the OAuth scope only applies to public API endpoints, not internal apps, which means WebDAV, OCS Share API, etc. I suggest to start with simple app-based scopes, combined with either "read-only" or "read-write" permissions. The WebDAV scope could have an additional "root" parameter to specify a root (chroot) in which the app can access. This might be achievable using SabreDAV plugins. The other APIs need a mechanism to recognize the scope and limit themselves accordingly. |
Idea (before I forget):
|
As discussed:
|
👍 |
👍 |
Would love to see this! |
We're past feature freeze, moving to 9.1 |
@ChristophWurst has implemented token based auth for 9.1. @DeepDiver1975 We should probably see if we can build upon it and evolve it into an OAuth 2.0 compatible mechanism because firewalls like BigPoint F5 are introducing support for OAuth 2.0 as well. Moving milestone to 9.2 to research then. |
First step: introduce the base work for oauth2 authentication @PhilippSchaffrath. Everything else like permission scoping should be done later as a second step. |
@PVince81 means we need acces/refresh tokens, clients and grants, i would probably need to implement scopes too but that would be an empty implementation at first. The grants we need right now:
Also a simple resource server to protect apis. This might be tricky because of our different routings/controllers. I imagine we don't want to protect everything. |
We shall only care about two different endpoints to pretect: webdav and our OCP\AppFrameWork\Controllers. |
That will make life in clients much easier, for sure. |
And this is what will bring back the pain again, I guess :D |
I head there is an for that ? Link then close ? |
OAuth 2.0 support is a key requirement if we want to start make ownCloud attractive as a platform for third-party developers. (e.g. if we want that they integrate ownCloud into their application)
Basically, OAuth is a protocol that allows third-party applications to request access to protected informations without providing the password to another party.
Currently, third-party applications have to use Basic Authentication (that is sending the username and the password) to access the ownCloud instance which has the following disadvantages:
Instead of using passwords for authorization OAuth is using unique tokens for every client. In OAuth, the client requests access to the needed resources (scopes) by redirecting the user to a website where he has to approve these permissions.
For example, a user might grant a "mobile news" application only access to the "news" API. Instead of entering his own credentials into the application the user just has to approve authorize the application via the ownCloud web interface.
User stories
Acceptance criteria
Scopes
core
files
files_sharing
Considerations
As applications should be able to register their own scopes (e.g. "contacts:read" to allow an application to read all contacts) we need it to make it as easy as possible to define their own scopes and which permissions they do grant.
I'd propose that we add the definitions of the scopes to "appinfo.xml", since we might reuse them in future for something else than OAuth we should give them a generic name.
$1
refers in this case to the first parameter,$2
would refer to the second parameter etc. (see below for some examples)- Those values are used to explain the permissions to the end-user when granting authorization.To define which controllers are accessible by a scope we should use the annotations of the appframework:
The scopes are specific for a specific application, if the above controller would be in the "contacts" app it would use the "read" and "write" scope definition from it. If it wants to check other permissions the full scope name (prefixed with the application identifier and a
:
) has to be provided:To read the parameters (e.g.
files:foo('/blah/', 'foo')
)$this->scope->0->0
can be used. This will return the first argument of the first scope (/blah/) defined in @scope.$this->scope->0->1
would return the second parameter of the first agument (foo).In our legacy applications which are not using the AppFramework we could use a function call as following:
It shall be noted that if no scope is defined no access will be granted. To allow any scope
*
can be used as wildcard. (@Scope('*')
)Summoning @karlitschek @MTRichards @DeepDiver1975 @Raydiation
Please:
The text was updated successfully, but these errors were encountered: