...
This feature allows a user to sign-in via a third-party service, such as Google, Yahoo or Facebook. The result of the OAuth 2.0 authentication flow is a username and access to whatever user account details are within the authorized scope, such as email address. Fedora is then free to use these user details to create a local user account or assign privileges as required for Fedora authorization. (All that this work flow provides is user authentication.)
OAuth Roles
- Client Application - Fedora
- Authorization Service - Google
- Resource Server - Fedora
OAuth 2.0 Authorization of Third-Party Applications
...
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.
OAuth Roles
- Client Application - Custom Fedora Front End
- Authorization Service - Fedora
- Resource Server - Fedora
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?
...