We have a frontend hosted on Pantaris, which uses a backend deployed “outside” Pantaris in Azure.
I’m looking for a solution in this hybrid scenario, when the frontend hits some endpoint at the backend with an access token issued by Pantaris so that the backend can extract user information from that token in order to decide if that user is allowed to access that endpoint. Additionally, the user should just login once to Pantaris only.
As a consequence, doing yet another Authorization Code Grant Flow to get a token for the backend is a no-go. I also found the feature “technical user” on pantaris-latest.de, which maps to the Client Credential Grant Flow, which has no notion of an user. It’s also not convenient to add the user information to the body of the HTTP Request to let the backend know, who wants to use its service.
What solution can you suggest for this scenario?
Additionally, the user should just login once to Pantaris only.
The PKCE flow should not need any user-inputs, when the sessions are in sync. So a user only logs in once, even if there a multiple login flows (basically just some redirects).
As a consequence, doing yet another Authorization Code Grant Flow to get a token for the backend is a no-go
This flow is designed for third party hosted frontend.
I also found the feature “technical user” on pantaris-latest.de, which maps to the Client Credential Grant Flow, which has no notion of an user.
You can map the cliendId of the jwt to users.name for service-accounts. Might be worth to introduce a stable field or overwritting sub like for human users 
What solution can you suggest for this scenario?
The tokens, which are used internally on pantaris hosted stuff (including your frontend) are not meant to be used by apps. We provide the user-information for all pantaris hosted parts independent of the token. See docs. For your scenario the easiest way is to add a backend-for-frontend, which is hosted on pantaris as well. Use the provided context information of pantaris to access your azure backend and secure the service-to-service communication independent of our tokens (e.g. certs, api tokens).