...
| Note |
|---|
This OAuth 2.0 implementation is experimental. |
OAuth 2.0
OAuth 2.0 User Authentication
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, etc..
- Resource Server - Fedora
OAuth 2.0 Application Authorization
From the OAuth 2.0 specification:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
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 application authorization can happen within the OAuth workflow. While OAuth is supported and encouraged, applications can still use container-level authentication, obtaining a container role and matching access. Therefore OAuth support is not required of all Fedora client applications.
OAuth Roles
- Client Application - custom front end, fedora proxy, or message-driven service
- Authorization Service - Fedora
- Resource Server - Fedora
OAuth Token Scopes (Proposed)
| scope | authorizer | definition |
|---|---|---|
| forward credentials | fedoraAdmin role | ability to forward end-user credentials in headers |
| fedora administrator | fedoraAdmin role | ability to act in the fedoraAdmin role |
| * on behalf of X | fedoraUser X | ability to forward end-user X user principal |
| read only | both | may only read data |
| until time T | both | authorizes for a limited time T |
* for future consideration: A user with the fedoraUser role could grant tokens within a scope that is limited by their own user id credentials. The application would be able to act on their behalf. One token per app user is the OAuth model we commonly see. Otherwise an app would have to track which token to use within some smaller context.
FAQ
...
- This will vary based on your authentication system. An OAuth token with on-behalf-of scope are limited to the access granted to that user, and their associated principals as retrieved by the configured principal factories. In other words, principal factories may bring more credentials into the security context. Depending upon your environment, this may or may not be equal to the access of the actual logged in user.
...
- Yes, access tokens may be assigned roles within the repository. This is especially useful for limited application access to a subtree.
...
| Excerpt Include | ||||
|---|---|---|---|---|
|
...