Issuer URL for MS Teams bot framework

Hi S, Carol,

Just checking in to see if you had a chance to review the previous response. 

Your feedback would be very helpful in ensuring everything is on track. 

HI @Kudos-Ng
Yes, We are migrating from kyma API rule from V1 to V2, while testing /messages endpoint is not working. So for testing bot’s message endpoint manually for debugging purposes I'm trying via Bruno.

Is there anywhere else we need to white list the Issuer URL? As I am not able to view logs for /message endpoint, even in azure portal only this logs I am able to see.

Hi S, Carol,

Thank you for sharing the updated context.

After reviewing the document you provided and the Kyma migration guide here: https://github.com/kyma-project/api-gateway/blob/main/docs/user/apirule-migration/01-83-migrate-jwt-v1beta1-to-v2.md, I understand that Kyma APIRule requires migration to v2, and in this version an explicit issuer must be configured. To validate tokens from the Bot Connector service to your bot’s /api/messages endpoint, you are currently testing manually.

Here are some important points I’d like to share:

• About JWT tokens from Bot Connector service: These tokens are issued and signed by Microsoft’s Bot Connector service. Microsoft does not provide any official method to manually simulate these tokens for testing the /api/messages endpoint. The documentation only explains how to validate JWT tokens, not how to mint them for manual testing.
  
• To confirm the correct issuer and JWKS URI: You can retrieve them from the OpenID configuration endpoint: GET https://login.botframework.com/v1/.well-known/openidconfiguration This will give you the exact issuer and jwks_uri values required for Kyma APIRule v2 configuration.
• Why you don’t see logs in Azure: If Kyma APIRule rejects the request due to issuer mismatch, the request never reaches your bot’s message endpoint, so no logs appear in Azure Bot Service.
• Recommended way to test after configuration: Once you update the issuer and JWKS URI in Kyma APIRule, test by sending a message to your bot from the Microsoft Teams client. This ensures the Bot Connector service calls your /api/messages endpoint with a valid token, allowing you to verify that authentication and routing work correctly.

I hope this helps clarify the authentication flow and gives you a clear path to validate your setup.

Hi @Kudos-Ng
Thanks for the reply and for the information you provided.

We always test by sending a message to the bot from the Microsoft Teams client. Since we did not have any logs, we also tried calling the endpoint manually. When we were on the V1 API rule, we were retrieving the issuer and jwks_uri values from the OpenID configuration endpoint: GET https://login.botframework.com/v1/.well-known/openidconfiguration At that time, we never faced this validation issue.

We also reached out to the Kyma API Gateway team, and they confirmed that everything looks fine on their side and that no additional whitelisting is required.

Since we are getting blocked at the gateway layer while validating the issuer, is there any Azure-supported approach to configure noAuth so that we can skip the gateway-level issuer validation and instead perform token validation entirely at the application layer?

Hi S, Carol,

Thank you for clarifying.

It seems you have already followed the correct approach by using: GET https://login.botframework.com/v1/.well-known/openidconfiguration

to configure the issuer and jwks_uri in your Kyma APIRule v2, but it still doesn’t work. You also confirmed with the Kyma API Gateway team that there are no issues on their side, so exploring an Azure-supported approach to skip gateway-level issuer validation makes sense.

I looked into this and found that Kyma supports a noAuth access strategy, which you can configure for your /api/messages endpoint. This will allow the gateway to pass requests without JWT validation, and you can then implement token validation entirely at the application layer using the Bot Framework SDK.

Here’s the Kyma documentation for reference: https://kyma-project.io/external-content/api-gateway/docs/user/custom-resources/apirule/04-15-api-rule-access-strategies.html#configuration-of-the-noauth-access-strategy
Note: Microsoft is providing this information as a convenience to you. These sites are not controlled by Microsoft, and Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please ensure that you fully understand the risks before using any suggestions from the above link.

You can consider applying this for your message endpoint and then implement token validation at the endpoint itself.

Hi @Kudos-Ng
I have tried noAuth as well, given in the documentation. I am facing the same issue,

Looks like azure does not support noAuth, Can you please confirm if it is possible, if yes, is there any documentations around this?

Hi S, Carol,

Thank you for following up and sharing more details.

Regarding your question “Looks like Azure does not support noAuth”, I’d like to clarify:

• The previous suggestion about noAuth refers to Kyma APIRule gateway configuration.
• Azure Bot Service itself does not provide a “No Auth” option because JWT validation is the minimum security mechanism for API communication. There is no way to disable authentication on Azure’s side.

I reviewed Kyma documentation and found this tutorial: https://kyma-project.io/external-content/api-gateway/docs/user/tutorials/01-40-expose-workload-noauth.html
Note: Microsoft is providing this information as a convenience to you. These sites are not controlled by Microsoft, and Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please ensure that you fully understand the risks before using any suggestions from the above link.

Since you are migrating to APIRule v2, Kyma’s docs highlight an important requirement:

Please verify that Istio sidecar injection is enabled for your bot workload. Without this, APIRule v2 (including noAuth) may not function correctly, and the gateway will block traffic before it reaches your bot’s /api/messages endpoint.

Hi S, Carol,

Just checking in to see if you had a chance to review the previous response. 

Your feedback would be very helpful in ensuring everything is on track. 

Hi @Kudos-Ng
I have tried all the approaches you mentioned, but unfortunately none of them worked. I have also verified that all the prerequisites are met, and our cluster does have sidecar injection enabled.

I understand that Azure Bot Service does not offer a “noAuth” option and that JWT validation is the minimum required security mechanism for API communication. However, could you please confirm whether Azure Bot Service allows noAuth at the gateway layer?

Additionally, our application exposes four endpoints, and the /api/health endpoint, which also uses JWT authentication, is working correctly. This indicates that the authentication scheme itself is not the issue. Our current assumption is that the problem may be related to the issuer configuration on the Microsoft side rather than the setup within our cluster.

healthRule:
    methods: |
      ["GET"]
    jwks:
      trustedIssuers: https://integration.api.[Moderator note: personal info removed].com
      url: https://www-integration.api.[Moderator note: personal info removed].com/oauth2/v0/jwks

messagesRule:
    methods: |
      ["POST"]
    jwks:
      trustedIssuers: https://api.botframework.com
      url: https://login.botframework.com/v1/.well-known/keys

If not, is there an alternative approach we should consider? We are currently blocked, so any guidance you can provide would be greatly appreciated.

Hi S, Carol,

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

At this point, I regret to inform you that I don’t have any additional insights to share on this matter. I’ve conducted further research; however, due to limitations in simulating the environment and the absence of official documentation, I haven’t been able to uncover new findings.

That said, I would recommend exploring discussions on platforms such as GitHub or Microsoft Tech Community, where seasoned technical experts often share valuable perspectives. These forums can provide alternative viewpoints and practical experiences that may help address your concerns.

Best regards,

HI @Kudos-Ng
I think I have made some progress, Upon debugging, I have figured out that the access token I am receiving to validate /messages endpoint is generated differently and not from this endpoint mentioned in the documentation.

Could you please provide the endpoint that generates the access token to validate /messages endpoint for Authenticating requests from the Bot Connector service to my bot?

Thank you.

Hi S, Carol,

Thank you for coming back and sharing more details.

Based on what I’ve researched, here’s what I can clarify:

• There is no public endpoint for developers to generate the token used by the Bot Connector service when calling your bot’s /api/messages endpoint. These tokens are issued internally by the Bot Connector service when it sends activities to your bot. This is why the documentation only provides the OpenID configuration URL: GET https://login.botframework.com/v1/.well-known/openidconfiguration for validation purposes, not for token generation.
• Any token you generate via: POST https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token is for outbound calls (from your bot to Bot Connector service), not for inbound requests from the Bot Connector service to your bot’s /api/messages endpoint.

If you are looking for an alternative way to test and debug your authentication gateway, you can consider using Bot Framework Emulator.

Note: While the Emulator uses the same authentication technologies described in the documentation, it cannot impersonate the real Bot Connector service. Instead, it uses the Microsoft App ID and Microsoft App Password you provide when connecting the Emulator to your bot to create tokens that mimic those your bot would generate.

I hope this information helps clarify your question.

Hi @Kudos-Ng
Can you please confirm if the token generated by the bot connector to authenticate the bot has "sub" claim, as the product kyma uses for authorization in APIRule v2 requires it.