Oauth Server #224
Description
Rationale
In order to make the Meeds Software a solution other tools can "call", we need to provide a oAuth Server.
For example, let's say we want to use an agent to help users create a space with a dedicated layout, a customized navigation and for which users are invited. A prompt is done and then the space is created as expected, thanks to this flow.
In order to enable this, it is then needed to implement a oAuth Server so tokens can be authorized and used by two services, incl. meeds one and another.
1. Functional Requirements
Top User Stories
Ability to read / write on meeds
When a service wants to use a Meeds platform in a flow, then users have to consent to such use.
Thus, a consent to read and/or write to the platform will be displayed to users.
For now, a standard consent window/popup will be used and it will be customized once enabled.
Admin UI to allow use of oAuth
In case the platform administrators does not want to allow use of oAuth access from third-party tools, then an option will be provided in the platform settings option from applcations > oAuth clients
User settings
From user settings, it will be possible to edit or delete oAuth Apps.
From there, apps will be listed and it will be possible to edit permissions of app and get the Client ID if needed
Impacts
Gamification
N/A
Notifications
N/A
Analytics
N/A
Unified Search
N/A
2. Technical Requirements
Expected Volume & Performance
Security
Extensibility
Configurability
Upgradability
Existing Features
Feature Flags
| Property Name | Default Value | Target Audience | Functional Behaviour |
|---|---|---|---|
Other Non Functional Requirements
3. Impacts
Documentation
Training
4. Software Architecture
Security
Access
- GUI
- API
Services & processing
- Ex: Scheduled Jobs
Data and persistence
- Macro data model
- Persistence layer
- Use of caches
Clustering
Multitenancy
Integrations
Migration strategy
5. Annexes
- Reasoning that explain the technical choices
- Impacts
- References