...

Subject to the practical limitations explored below, Fedora will be designed such that authorization happens within the OAuth workflow.

While OAuth is supported and encouraged, applications can still authenticate via container-level "user authentication". OAuth support is not required of all Fedora client applications.

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?

...

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.

Forwarding Credentials and Security Principals

Regardless of the approach used for authentication of third party apps, certain applications will need to forward security principals or other attributes on behalf of end users. These break down into two categories, named principals and credentials. The distinction is whether Fedora or the third part application constructed the distinct security principals used for authorization. To illustrate we take the example of an IP restriction. Let's say that the authorization policy, regardless of implementation, says that users "on campus" can access a resource, but otherwise they cannot. The third party can support this authorization in two ways. It can provide the IP address of the end user request or it can provide the named security principal "on campus". Since applications often act on behalf of end users with extended security attributes, such as those from Shibboleth, the ability to forward credentials to a central point of authorization is key. In mixed authentication environments, i.e. Fedora instances that support end-user and application requests, it is helpful to channel security credentials into a same pipeline for extracting the security principals that are the subject of authorization.

• Container User Role: forward credentials
• OAuth Token Scope: forward credentials

Establishing JCR Sessions

...