...
Applications can be authenticated by means of token credentials generated through the OAuth 2.0 framework.
Subject to the practical limitations explored below, Fedora will be designed such that authorization happens within the OAuth workflow.
Possible Limitations
- A token covers a certain scope of access, tied to the client app. Assuming that user privileges vary throughout a repository, can OAuth tokens be used to effectively record user privileges?
- One token per application or per app user, is the OAuth model we see in the wild. Otherwise an app would have to know which token to use within some smaller context.
- Similarly, how much access can a single OAuth token cover? Can they be patched or modified after authorization to cover more cases?
Implementation Questions
- Are OAuth mitigated operations subject to other access restrictions imposed on the user who authorized the token? (or the on-behalf-of user)
- Then ACL restrictions on the user would apply equally to the token-based requests they have authorized.
- Who will be able authorize third-party applications at the server's Resource Owner Authorization endpoint? (/authorize)
- fedora administrators
- who else?
- What scopes will govern token access?
- on behalf of user X (or security principal X)
- set of permitted actions (read, write) (Note that JCR 2.0 privilege discovery might align well with OAuth scopes.)
- within repository path /A/B/C
- between now and X months hence
- Which scopes are optional and which are mandatory, for whom?
- Do admins get to give away global permissions to apps?
- Are tokens authorized by normal users restricted to their current permissions?
- ?
A user with the fedoraAdmin role may authorize application access without any limits upon scope, including access equivalent to the fedoraAdmin role. A user with the fedoraUser role can only grant tokens within a scope that is limited by their own user credentials, since the application will only be able to act on their behalf. For specifics see the OAuth section below.
...