Content
View differences
Updated by Pavel Balashou almost 2 years ago
## Title
Provide OIDC generated access token to other apps. Support OIDC token exchange.
## Description
Ever more often Nextcloud is bundled with other applications, such as OpenProject, sharing one user session across the integrated applications via OIDC single sign on (SSO).
For deep integrations Nextcloud apps need to be able to make impersonated back-end to back-end API requests to bundled applications.
Up until now the impersonation was often achieved via OAuth2 flows, which has an inferior UX as it is pretty complex for user to understand. It requires involvement of the user. And the cognitive load often is too high. They fail. A better approach would be to use the trusted OIDC provider to hand out access tokens during SSO that then can be used to authorize requests to bundled applications. Then the user only needs to login and no further actions by the user are necessary.
We believe that `user_oidc` would be the ideal place for managing the access tokens. It has all the setup/configuration information needed to interact with the OIDC provider. Further it already receives the ID, access and refresh tokens.
As developers of [OpenProject Integration app](https://github.com/nextcloud/integration_openproject) we would like to have access to the access token with sufficient privileges priviliges to use it for authorizing outgoing requests to the OpenProject server. By sufficient privileges we mean, for instance, presence of OpenProject server client\_id in `aud` claim of the access token and required scopes in `scope` claim. We see two possible scenarios how to get such a token:
1. OIDC provider is configured to add OpenProject client\_id to `aud` aud claim for access token issued to Nextcloud client\_id.
2. OIDC provider is configured to support [token\_exchange](https://datatracker.ietf.org/doc/html/rfc8693). Then the original access token access\_token can be exchanged for another one exclusively used to access OpenProject (having only the OpenProject client\_id in the `aud` aud claim).
Then the access to this access token access\_token could be given to other Nextcloud applications, `integration_openproject` among them, as an event subscription or in any different way.
Besides that the following cases should be taken into consideration:
* access token has been expired. In this case we need a way to get a fresh refresh an expired access token.
* refresh token has been expired. Probably, it means user has to renew its session.
should be considered. We are not sure about the exact API that could be provided to cover these scenarios. API.
Kindly let us know if what we ask is possible to achieve.
Provide OIDC generated access token to other apps. Support OIDC token exchange.
## Description
Ever more often Nextcloud is bundled with other applications, such as OpenProject, sharing one user session across the integrated applications via OIDC single sign on (SSO).
For deep integrations Nextcloud apps need to be able to make impersonated back-end to back-end API requests to bundled applications.
Up until now the impersonation was often achieved via OAuth2 flows, which has an inferior UX as it is pretty complex for user to understand. It requires involvement of the user. And the cognitive load often is too high. They fail. A better approach would be to use the trusted OIDC provider to hand out access tokens during SSO that then can be used to authorize requests to bundled applications. Then the user only needs to login and no further actions by the user are necessary.
We believe that `user_oidc` would be the ideal place for managing the access tokens. It has all the setup/configuration information needed to interact with the OIDC provider. Further it already receives the ID, access and refresh tokens.
As developers of [OpenProject Integration app](https://github.com/nextcloud/integration_openproject) we would like to have access to the access token with sufficient privileges
1. OIDC provider is configured to add OpenProject client\_id to `aud`
2. OIDC provider is configured to support [token\_exchange](https://datatracker.ietf.org/doc/html/rfc8693). Then the original access token
Then the access to this access token
Besides that the following cases should be taken into consideration:
* access token has been expired. In this case we need a way to get a fresh
* refresh token has been expired. Probably, it means user has to renew its session.
Kindly let us know if what we ask is possible to achieve.