Custom Connector Gives Invalid Access Token Issue - Token Audience Mismatch

(1) Share

Report

Posted on by CU04051118-0

Hi Team,

Need your quick help, previously we have built Copilot Studio agent for user and did a integration with workday to retrieve users information in copilot studio agent. We are currently using Manual Auth and integration with workday is SAML based.

Now we are planning to move authentication from Manual auth to MS auth, so to achieve that we are building one custom connector which will use OBO configuration to interact with workday. Configuration is done as per steps mentioned in MS link (https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-custom-connector-on-behalf-of).

and workday api methods is configured under definition.

While calling workday methods from custom connector, it is failing with the error "Invalid Access Token" and after decoding JWT token, i found that the audience in the token is "apihub.azure.com".

Ideally the token should be generated from the app registration which is authorized to communicate with workday.

Can someone help, how we can resolve this issue ? Is there any better way to achieve this or any way if could translate apihub.azure.com token to app registration designed to communicate with workday.

Categories:

Calling actions from Copilot Studio

I have the same question (0)

All responses (7)

Answers (0)

Sort by

Prasad-MSFT Microsoft Employee on at

Like (2)

Report
Copy link

Link copied!
The aud = apihub.azure.com token is expected in Copilot Studio/Power Platform custom connectors. That token is intended for the Power Platform API Hub, not for Workday.

Why you're getting "Invalid Access Token"
You're likely passing the incoming bearer token directly to Workday:

Copilot Studio → Custom Connector → Workday

Workday validates the audience and rejects it because it expects a Workday-specific access token, not an API Hub token.

Can you translate the apihub.azure.com token?

No, not directly. You cannot simply convert or rewrite the token.
Recommended approach
Use an intermediate API (Azure Function/App Service/APIM):

Copilot Studio
↓
Custom Connector
↓
Azure Function/API
↓ (OBO exchange)
Entra ID
↓
Workday token
↓
Workday API

The middleware performs the On-Behalf-Of (OBO) flow and requests a new access token for the Workday resource.

The issue is not that Copilot Studio is generating the wrong token. The apihub.azure.com audience is normal. The key question is whether Workday is configured as an OAuth resource that supports OBO. If it's SAML-only, you'll need a middleware/service-based approach rather than passing the Copilot token directly to Workday

Was this reply helpful? Yes No
Suggested answer

Valantis 6,488 on at

Like (2)

Report
Copy link

Link copied!

Hi @CU04051118-0,

Since Workday is SAML-based, the Azure Function needs to handle the token exchange in two steps:

1. Receive the apihub.azure.com token from the custom connector and validate it against your Entra app registration

2. Exchange it for a Workday SAML assertion or OAuth token using the OBO flow if Workday supports OAuth, or use a service account with SAML if it doesn't

For the custom connector configuration, point the connector's API endpoint to your Azure Function URL instead of directly to Workday. The Azure Function becomes the backend that handles auth and forwards the request to Workday.

In the custom connector definition, the security scheme stays as OAuth 2.0 with your Entra app registration. The Function validates the incoming Entra token, performs the Workday auth internally, and returns the Workday response back to Copilot Studio.

This pattern is the supported path confirmed by Microsoft docs for integrating with external systems that don't accept Entra tokens directly.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
CU04051118-0 12 on at

Like (1)

Report
Copy link

Link copied!

@Prasad-MSFT As per your recommendation, I have introduced a azure function which will perform OBO work and configure the same in custom connector so that we can call azure function directly using custom connector.

But again I am again blocked with same challenge, initially while calling azure function the token received to function via http request is having AUD as apihub.azure.com and when I a try to do OBO exchange, its failing with the error that there is a mismatch in audience.

So obo exchange is expecting a token from custom connector app registration and due to this AUD mismatch, process is failing.

Is there anything I am doing wrong here?

Was this reply helpful? Yes No
Prasad-MSFT Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!
The token received by the Azure Function has aud = apihub.azure.com, which means it was issued for the Power Platform API Hub, not for your Azure Function's App Registration.

For the OBO flow to work, the incoming token must be issued for the API performing the OBO exchange. If the Azure Function receives an API Hub token, Entra ID will reject the OBO request due to the audience mismatch.

Could you confirm:

Is the Azure Function protected by its own Entra ID App Registration/Application ID URI?

Is the custom connector configured to request a token for the Azure Function's audience?

What is the exact AADSTS error code/message returned during the OBO exchange?

The AADSTS error should help determine whether this is purely an audience mismatch or if there's an additional configuration issue.

Was this reply helpful? Yes No
CU04051118-0 12 on at

Like (1)

Report
Copy link

Link copied!
Prasad-MSFT
Thank you for your response.

I would like to explain our complete scenario and what we are trying to achieve.

Current Architecture

Phase 1 Implementation

During Phase 1 of the project, we developed a Copilot Studio agent that uses manual authentication to connect with Workday. The integration is required to enable users to:

Query their worker data

Perform Workday transactions such as:

Name changes

Address updates

Document requests

We are not using the out-of-the-box Workday connector because it does not meet our functional requirements. Instead, we implemented a custom authentication mechanism using SAML-based authentication. As part of this setup, Workday was configured as an Enterprise Application in Azure with SAML Single Sign-On (SSO) enabled.

New Requirement

As part of our next phase, we want to move away from manual authentication and leverage Microsoft authentication. To achieve this, we started implementing the On-Behalf-Of (OBO) flow using a Custom Connector, following the Microsoft documentation below:

https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-custom-connector-on-behalf-of

After completing the configuration, we created a connector definition that invokes one of the Workday APIs.

Issues Encountered

Issue 1: Invalid Access Token

When using the OBO approach to connect directly to Workday, we received an "Invalid Access Token" error.

Upon inspecting the access token, we found that the aud (audience) claim was set to:

apihub.azure.com

instead of the expected Workday audience.

Issue 2: OBO Exchange Through Azure Function

Based on your recommendation, we introduced an Azure Function as a middleware API and attempted to perform the OBO token exchange within the Azure Function.

Below are the details of our configuration:

Is the Azure Function protected by its own Entra ID App Registration/Application ID URI?

Yes. A dedicated App Registration has been created for the Azure Function.

Is the Custom Connector configured to request a token for the Azure Function's audience?

Yes. The access token received by the Azure Function contains the Azure Function's Application ID URI as the audience.

What is the exact AADSTS error returned during the OBO exchange?

While performing the OBO exchange, we receive the following error:

AADSTS399274: The application with App ID 'xxxxxxxxxxx' is configured for SAML SSO and could not be used with non-SAML protocol. Trace ID: xxxxxxxxxxxxxxx Correlation ID: xxxxxxxxxxxx Timestamp: 2026-06-04 11:31:27Z

Could you please help us understand whether our overall approach is valid for a Workday integration that currently relies on SAML SSO, and what changes would be required to successfully implement the OBO flow?

Was this reply helpful? Yes No
Suggested answer

Valantis 6,488 on at

Like (1)

Report
Copy link

Link copied!

Hi @CU04051118-0,

AADSTS399274 is the confirmed blocker. It means the Workday enterprise application in Entra is configured for SAML SSO only, and OBO flow requires OAuth 2.0 on the target application. You cannot use OBO to exchange a token for an app that's SAML-only. Entra ID explicitly blocks this, which is what the error states.

This means the OAuth/OBO path to Workday is not possible with your current Workday Entra setup. You have two real options:

Option 1 (keep SAML): in the Azure Function, instead of OBO, use a service account approach. The Function validates the incoming Entra token (from the custom connector) to confirm the caller is a legitimate user, then generates the Workday SAML assertion itself using a service account or certificate that Workday trusts. This is essentially what your Phase 1 manual auth did, just moved to the Azure Function layer so users don't have to authenticate manually.

Option 2 (switch to OAuth): configure Workday to support OAuth 2.0 in addition to SAML. Workday does support OAuth 2.0 as a separate auth method. If your Workday admin enables OAuth and you update the Entra enterprise app registration to OAuth 2.0 instead of SAML, OBO becomes possible. This requires changes on the Workday side but gives you the cleanest long-term architecture.

Option 1 is faster to implement given your existing SAML setup. Option 2 is the correct long-term architecture if Workday OAuth can be enabled.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
CU04051118-0 12 on at

Like (0)

Report
Copy link

Link copied!

@Valantis Thanks for your response. Any idea which kind of configuration will be required on workday side as well as on azure side to achieve option 2 ?

Was this reply helpful? Yes No