Personal token for API access in third-party tools

[fschrempf]

Description

User Stories

As a system integrator I want to combine oCIS with other software components. In order to do that I would like to create a tool that acts as a bridge and uses the Libre Graph API to interface with oCIS. This backend tool needs to authenticate with the API in some way.

Therefore I need a way to create a persistent access token that can be used for API authentication as current auth flows are either only targeted at frontend clients (OIDC) or not recommended for production use (basic auth).

Value

• enable third-party backend integration through API

Acceptance Criteria

Definition of ready

• Everybody needs to understand the value written in the user story
• Acceptance criteria have to be defined
• All dependencies of the user story need to be identified
• Feature should be seen from an end user perspective
• Story has to be estimated
• Story points need to be less than 20

Definition of done

• Functional requirements
  • Functionality described in the user story works
  • Acceptance criteria are fulfilled
• Quality
  • Code review happened
  • CI is green (that includes new and existing automated tests)
  • Critical code received unit tests by the developer
• Non-functional requirements
  • No sonar cloud issues
• Configuration changes
  • The next branch of the ocis charts is compatible

[michaelstingl]

Sounds like …

• App Passwords / Tokens for legacy WebDAV clients #197

[micbar]

Please take into account that from a security POV we cannot use static tokens which have a global scope. That would give outside systems full control over your account and data.

I think we need an auth service which manages user created tokens which are scoped, like having only read access, write access to only one endpoint or only one space and so on.

that would need a graph Api implementation and a web app to create and destroy these tokens.

@michaelstingl @kulmann @tbsbdr @dragotin

[dragotin]

@micbar yes, I agree.

I would start with the following "spec":

• App Tokens always have the scope of a certain space. By default, users can create App tokens only to grant access to their personal space
• Tokens for project spaces can only be created by Space Managers.
• In the web admin page, all app tokens a user controls are listed and can be revoked. New ones can be created.
• App Tokens only allows up- and downloading data, no sharing

Advanced features:

• Have Read Write and Read Only tokens
• Allow creation of public links through App tokens
• Have an Expiry date of a App token
• Project space App tokens are visible at the space view for managers

@DeepDiver1975 would the "start-spec" be sufficient for migration?

[DeepDiver1975]

For the migration scenario we need a way to impersonate a user without interaction of the user or the administrator.

The intent is to create a service account which can impersonate any user up on request.
The same service account needs permissions to create users.

[dragotin]

Ok, so for migration we need more... but the small spec above stays relevant for normal App Tokens.

[DeepDiver1975]

but the small spec above stays relevant for normal App Tokens.

For use cases like caldav and carddav - yes 👍

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.