I am building a headless Next website that will consume the content delivery api to render the content curated in Umbraco, the Next web app is secured with OpenId and users login to the web app and acquires an access token that will be used to communicate with Umbraco, we have configured Jwt for Umbraco and we can resolve the users when requesting Umbraco resources, the issue we are trying to solve is securing the content delivery api, according to the documentation the only way to authorize users users to consume the content delivery Api is by acquiring another token from Umbraco which acts as an identity provider, given the nature of Jwt middleware when I try to execute an authorize request with the token passed from the Next web app I receive the the client_id is empty, this is true because Jwt configurations doesn’t have a client id, also there will be now auth flow to authenticate against as the user authentication flow is already executed at the frontend side, when I checked the base delivery controller I found that it’s decorated with an Authorize filter that requires a policy that mandates that only token issued by the OpenIddict schema. So my question is there a way to go around this or extend the Api to allow requests issued by my custom Jwt scheme as well?

What OpenId service are you using to authenticate the users and get the Jwt token for the front-end? If you change the front-end to authorize against umbraco always, then the JWT token will already be an umbraco-sourced token.

Thanks for your reply, so our solution provides the ability to login via OKTA, PING, ADFS or Azure Ad using the OpenId protocol, so our customers already have their own Identity providers, policies, … etc and the target is to be able to SSO so I can’t use Umbraco for this. Yes I scanned the channel yesterday before posting and saw a similar discussion a year ago but didn’t know if this already materialized to a roadmap feature or not, hopefully it will be coming soon as this is one of the core requirements