[Feature Request] Provide OIDC generated access token to other apps. Support OIDC token exchange.

​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 we would like to have access to the access token with sufficient privileges 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 claim for access token issued to Nextcloud client_id.

2. OIDC provider is configured to support token_exchange. Then the original access token can be exchanged for another one exclusively used to access OpenProject (having only the OpenProject client_id in the aud claim).

Then the access to this 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 access token.

• refresh token has been expired. Probably, it means user has to renew its session.

We are not sure about the exact API that could be provided to cover these scenarios. 

Kindly let us know if what we ask is possible to achieve.

@julien-nc @wielinde @SagarGi

Start by reviewing user_oidc’s existing handling of ID, access, and refresh tokens, then read the RFC 8693 token-exchange requirements linked in the issue. Define whether the provider configuration supports direct audience changes or token exchange, and how other apps would request tokens and handle expiry. Done requires an agreed API covering delivery, refresh, and session renewal.