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 (3)

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,290 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 8 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