Issue with Oauth2 redirect upon signing in on Declarative Agent with existing API plugin

[michellekeoy]

Describe the bug
Context: I am creating a custom declarative agent with an existing API plugin using OAuth2 authorization code flow.

What has been done so far:

• The declarative agent has been built, I can see and test it on teams
• OAuth client has been registered following this documentation, with authorize, token, and refresh routes, and scope. OAUTH2_CONFIGURATION_ID has been added to manifest.
• Followed this instruction: If your OAuth provider requires specifying allowed redirect URIs when registering your app, include https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect in the allowed redirect URIs. Side note: I am confused about this redirect URI specifically. How does it know which chat/agent to return to?
• I am able to get prompted to sign in to my security provider Okta.
• I get a popup to login with Okta, I am able to login to Okta with my credentials
• I am able to see in our Okta logs of a successful login (/authorize and /token endpoints are hit and successfully grant an access token)
• I see in the network tab 302s and 200s, no error codes can be seen.
• After logging in with Okta, the login popup turns into a blank page.
• I do not get redirected to the chat, and if I send another message to the chat, we get prompted to sign in with OAuth flow again.

To Reproduce
Not sure if you would be able to reproduce the behaviour, but I am happy to connect and show you on a call.

Expected behavior
I would assume we get redirected to the copilot chat with my custom declarative agent.

Screenshots
Screenshots have sensitive information, but they don't provide much. I have described to best ability above, let me know if you need more details!

VS Code Extension Information (please complete the following information):

• OS: Darwin x64 23.6.0
• Version 1.95.1 (Universal)

CLI Information (please complete the following information):

• OS: [e.g. iOS8.1]
• Version [e.g. 22]

[SLdragon]

Hi, @michellekeoy

I am confused about this redirect URI specifically. How does it know which chat/agent to return to?

The redirect URI is used to receive the token and will automatically close after consent, it will not return to any chat/agent.

Regarding your issue, it seems the Copilot API call failed with the token, so that it ask your consent again. This could be due to an invalid scope or other reasons. Could you share your OAuth registration info so I can take a look?

[michellekeoy]

@SLdragon Noted. Yes, where can I share that info in a secure place? Why did the API call fail if Okta has returned a success and I receive a 200? Scope is correct or else the access token would not have been granted.

[SLdragon]

Do you mean that your API service responded with a 200 status?

Can you check the API call logs in the service backend to see if it received the correct token and parameters?

[michellekeoy]

@SLdragon Yes, checked, correct. It is successful. It may be clearer if we hop on a call to debug instead, as I'm not sure I can send sensitive information in this forum. My timezone EST though

[SLdragon]

OK, you can find me on Teams [email protected]

[michellekeoy]

@SLdragon Requested you on Teams

[SLdragon]

Just talked with @michellekeoy , seems the issue is related to the declarative agent backend, and still investigate the root cause

[michellekeoy]

Spoke to @jofri-msft on this issue.

MS currently sends client credentials in both header and body. The auth provider Okta's token endpoint supports only one method of client credentials delivery at a time, which leads to the following error message:
"message": Failed to exchange code for OAuth token. Http Status Code: 'Unauthorized', Error: '{"error":"invalid_request","error_description":"Cannot supply multiple client credentials. Use one of the following: credentials in the Authorization header, credentials in the post body, or a client_assertion in the post body."}',

Requesting if MS would be able to make the client authentication method configurable between header vs POST request similar to OpenAI GPT config.

[SLdragon]

Thank you @michellekeoy for your feedback. We will track this issue and inform you of any backend updates.

[ilia-beliaev-miro]

I have stumbled upon a similar issue. In my case, OAuth token provider is Miro.

Declarative agent goes through the token retrieval process, I see in the network tab eventually a call to store the retrieved auth token, but the call to my locally running service (behind ngrok) never comes.

Just out of curiosity I've tried using the OAuth client generated by this exercise - https://learn.microsoft.com/en-us/training/modules/copilot-declarative-agent-api-plugin-auth/5-exercise-integrate-api-plugin-oauth - and it worked. Could it be that at current stage only some specific token or scope formats are supported?

[SLdragon]

@ilia-beliaev-miro, the problem may same as michellekeoy mentioned, token exchanged step failed, so you will never receive the calls to your locally running service. If you can access Miro backend, maybe you can take a look token exchange logs to check whether there are some error logs~

[ilia-beliaev-miro]

@SLdragon I see token retrieval also going on as planned and resulting in 200 OK. I also see the code getting seemingly stored (see screenshot). Just after the token request nothing happens.
If I turn off OAuth in api manifest - requests are going through, so there is no problem with the actual API accessibility.

[SLdragon]

OK, you can decode the response token to check whether scope and other properties is expected.

[ilia-beliaev-miro]

@SLdragon Even if the scope were not correct, the request would still have been issued, right? It would potentially later fail on the receiving side, but that' not what I observe. The request after the OAuth is never executed.

[SLdragon]

Hi, @ilia-beliaev-miro ,
The Copilot backend orchestration engine will attempt to exchange the token and make the request. These requests are not visible from the client side. For requests that are not triggered, I believe the issue lies in the token exchange process. (Where did you see the token? If it is on the client side, I believe it is not the token for your request but rather the token used by Teams)

If you could check the logs from your identity provider for the token exchange/consent steps, it would help identify the problem.

[swamisnawale]

Hi @michellekeoy, I'm facing the same issue that you have mentioned. I built a copilot agent that calls MS Graph API with OAuth enabled. Until yesterday, it was working but now when I sign in, the login popup is blank and show below error.

Error: 'Something went wrong. Please try again.' Timestamp: '2024-12-20T02:42:54.7026739+00:00' RequestId: 'NoContext-f97f6cc5-8a87-41fb-9ae7-b769e95eb*'**