Required confirmations before submitting
Issue Description
Summary
On a self-hosted CIPP-NG deployment, enabling ordinary CIPP API clients and selecting Save to Azure configures App Service EasyAuth with api://<client-id> in allowedAudiences, but does not add the bare application/client ID for those clients.
The API client app registrations use requestedAccessTokenVersion: 2. A client-credentials token requested with scope api://<client-id>/.default is successfully issued by Entra, with the token's aud claim set to the bare application ID. EasyAuth then rejects the otherwise valid token with HTTP 401 because only api://<client-id> is allowed.
The current Set-CippApiAuth implementation already adds bare app IDs for MCP clients, but not for ordinary enabled API clients.
Steps to reproduce
- Deploy or update a self-hosted CIPP-NG instance.
- Create a normal CIPP API client with MCP disabled and a valid CIPP role.
- Select Save to Azure from the CIPP API integration page.
- Request a v2 client-credentials token from the hosting tenant using scope
api://<client-id>/.default.
- Confirm token issuance succeeds and
aud is the bare application ID.
- Call a CIPP endpoint permitted by the client's role.
Actual behavior
App Service EasyAuth returns HTTP 401 before the request reaches CIPP authorization. Live EasyAuth configuration contains api://<client-id> but not <client-id> in allowedAudiences. Repeating Save to Azure recreates the same configuration.
Expected behavior
Every enabled v2 CIPP API client should have both audience forms accepted:
api://<client-id>
<client-id>
Alternatively, CIPP should configure or request normal API-client tokens so the issued aud consistently matches the audience written to EasyAuth.
Workaround and validation
Adding the bare application ID to EasyAuth allowedAudiences, then restarting App Service so the platform-injected authentication configuration refreshes, resolves the failure:
- a permitted read-only endpoint returns HTTP 200;
- a privileged endpoint outside the client's CIPP role returns HTTP 403;
- a narrowly scoped Standards client produces the same expected 200/403 authorization behavior.
This confirms the initial 401 occurs at EasyAuth audience validation rather than within CIPP RBAC.
Suggested change
In backend/Modules/CIPPCore/Public/Authentication/Set-CippApiAuth.ps1, add each enabled API client's bare ID to $AllAudiences as well as api://$id, not only MCP client IDs. Keep allowedApplications as the application authorization gate.
The warmup reconciliation in backend/Modules/CIPPCore/Public/Authentication/Initialize-CIPPAuth.ps1 should construct the same desired audience set so it does not remove the correction later.
All tenant IDs, application IDs, IP addresses, hostnames, tokens, and secrets have been redacted.
Environment Type
Non-sponsored user
Front End Version
10.9.1
Back End Version
10.9.1
Relevant Logs / Stack Trace
Required confirmations before submitting
Issue Description
Summary
On a self-hosted CIPP-NG deployment, enabling ordinary CIPP API clients and selecting Save to Azure configures App Service EasyAuth with
api://<client-id>inallowedAudiences, but does not add the bare application/client ID for those clients.The API client app registrations use
requestedAccessTokenVersion: 2. A client-credentials token requested with scopeapi://<client-id>/.defaultis successfully issued by Entra, with the token'saudclaim set to the bare application ID. EasyAuth then rejects the otherwise valid token with HTTP 401 because onlyapi://<client-id>is allowed.The current
Set-CippApiAuthimplementation already adds bare app IDs for MCP clients, but not for ordinary enabled API clients.Steps to reproduce
api://<client-id>/.default.audis the bare application ID.Actual behavior
App Service EasyAuth returns HTTP 401 before the request reaches CIPP authorization. Live EasyAuth configuration contains
api://<client-id>but not<client-id>inallowedAudiences. Repeating Save to Azure recreates the same configuration.Expected behavior
Every enabled v2 CIPP API client should have both audience forms accepted:
Alternatively, CIPP should configure or request normal API-client tokens so the issued
audconsistently matches the audience written to EasyAuth.Workaround and validation
Adding the bare application ID to EasyAuth
allowedAudiences, then restarting App Service so the platform-injected authentication configuration refreshes, resolves the failure:This confirms the initial 401 occurs at EasyAuth audience validation rather than within CIPP RBAC.
Suggested change
In
backend/Modules/CIPPCore/Public/Authentication/Set-CippApiAuth.ps1, add each enabled API client's bare ID to$AllAudiencesas well asapi://$id, not only MCP client IDs. KeepallowedApplicationsas the application authorization gate.The warmup reconciliation in
backend/Modules/CIPPCore/Public/Authentication/Initialize-CIPPAuth.ps1should construct the same desired audience set so it does not remove the correction later.All tenant IDs, application IDs, IP addresses, hostnames, tokens, and secrets have been redacted.
Environment Type
Non-sponsored user
Front End Version
10.9.1
Back End Version
10.9.1
Relevant Logs / Stack Trace