Share via

Identity & Authentication with Teams Chat bot using Microsoft 365 Agent

Jef Aldrich 0 Reputation points
2026-06-10T21:55:58.4+00:00

I have built a teams chatbot that uses the Microsoft 365 Agent SDK in python.

Today it integrates with Azure AI Foundry for LLM needs and Azure AI Search service for RAG responses from our knowledge base articles

This all works pretty good.

I want to extend functionality by integrating with other systems and thats where i am looking for guidance.

In particular i want to make sure i am handling identity & authentication properly when trying to integrate with other systems.

For example if i want a user to ask questions about jira ticket or confluence document i can reach out to those services as a service account and query them.

However it will return results that the user shouldn't see. How can i pass authentication token from the teams bot to a 3rd party system on the backend.

I can pass details like the username or userprincipalname of the user but that alone wont authenticate to various back end applications.

What is the best practice for handling this scenario?

FYI....some of our apps are azure integrate Oauth and SAML and legacy LDAP.

Microsoft Teams | Development
Microsoft Teams | Development

Building, integrating, or customizing apps and workflows within Microsoft Teams using developer tools and APIs

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Hin-V 15,490 Reputation points Microsoft External Staff Moderator
    2026-06-10T22:50:11.6266667+00:00

    Hi @Jef Aldrich

    Thank you for reaching out. 

    First, I’d like to clarify that this is a user‑to‑user support forum. Moderators participating here do not have access to backend systems, nor can we directly intervene in Microsoft product functionality. Our role is limited to providing technical guidance and sharing best‑practice recommendations based on reported issues, requests, and scenarios. 

    From your description, it sounds like you want the Teams chatbot to query external systems (such as Jira and Confluence) on behalf of the individual end-user. This ensures the returned data respects that user’s specific permissions, rather than using a shared service account with broader privileges. 

    Based on my research, you could consider to use Single Sign-On (SSO) combined with the On-Behalf-Of (OBO) flow with Microsoft Entra ID. This is the standard and secure pattern for Microsoft 365 Agents SDK (Python) to propagate the user’s identity and permissions from Teams through your bot to the backend and third-party systems. 

    This approach brings several important benefits, such as: It ensures the bot only returns data the current user is allowed to see, improves overall security and compliance by following the principle of least privilege, provides a seamless experience for users with no additional logins required, and is fully supported by the Microsoft identity platform making it scalable and easier to maintain. It also offers better auditability since actions are performed under the real user identity. The solution works especially well with Azure-integrated OAuth applications, and can be combined with Atlassian’s Entra ID integration for Jira Cloud and Confluence Cloud. 

    User's image

    You can refer more via: 

    Microsoft identity platform and OAuth2.0 On-Behalf-Of flow - Microsoft identity platform | Microsof… 

    Test agents using the Microsoft Agent 365 SDK | Microsoft Learn 

    OAuth 2.0 Bot Authentication with Azure - Teams | Microsoft Learn 

    Configure Atlassian Cloud for Single sign-on with Microsoft Entra ID - Microsoft Entra ID | Microso… 

    Please note that this summary is based on my own findings and may not fully address your concerns. To help you reach your goal more effectively, I recommend engaging with [GitHub Community Forum] for a deeper technical dive or to connect with individuals who have relevant experience and expertise. Some approaches may behave differently or be restricted depending on your specific environment and configuration. These forums include many experienced developers and Microsoft specialists who can assist with troubleshooting and guidance.  

    I hope this helps. 

    Please feel free to correct me if I misunderstood your request. If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

    Was this answer helpful?

  2. AI answer

    2026-06-10T21:56:31.6366667+00:00

    Use OAuth-based user authentication and tokens issued by trusted identity providers; do not forward Teams access tokens directly to arbitrary back-end systems.

    For a Teams bot built with the Microsoft 365 Agent SDK, the recommended pattern is:

    1. Use Azure Bot Service OAuth for user sign-in
      • Configure OAuth connections on the Azure Bot resource so that the bot can obtain user tokens from identity providers (for example, Microsoft Entra ID or other supported providers such as Google, GitHub, etc.).
      • The bot uses OAuth 2.0 to get a token on behalf of the signed-in user. The user authenticates only with the identity provider; the bot never handles raw credentials.
      • Guidance for this model is described in the bot authentication concepts and Teams bot authentication docs. These emphasize using identity providers and OAuth 2.0 rather than passing usernames or passwords.
    2. Use identity providers for each secured resource
      • When an agent or bot is registered in Azure, it gets a Microsoft Entra ID application that secures channel-to-bot access.
      • For each external secured resource (for example, Jira, Confluence, or other APIs), create a separate Microsoft Entra ID application or other supported identity provider configuration. This application issues tokens that the bot uses to call that resource on behalf of the user.
      • This ensures that access to each system is governed by that system’s own authorization rules and scopes, not by a generic service account.
    3. Leverage federated identity credentials where applicable
      • Federated identity credentials can be used so that the Azure AI Bot Service (or agent) obtains tokens from Microsoft Entra ID without the agent handling secrets.
      • The agent uses the token generated by Azure to access online resources that require user authentication, again without collecting user credentials.
    4. Use Teams user authentication flows for Teams-hosted experiences
      • For Teams apps and bots, use the Teams user authentication guidance based on OAuth 2.0.
      • The flow is: user signs in → identity provider issues token → bot receives token → bot calls the secured resource with that token.
      • This applies whether the resource is Microsoft Graph or another API configured as an identity provider.
    5. Do not rely on usernames alone
      • Passing only userPrincipalName or username is not sufficient for secure authorization. Tokens from an identity provider are required so that downstream systems can enforce their own authorization policies.
    6. Handle sign-in and token events correctly in the bot
      • In the SDK samples, the bot uses dialogs and OAuth prompts to initiate sign-in and then handles token response events to continue the dialog once a token is available.
      • For Teams bots in Python, the on_teams_signin_verify_state and on_token_response_event handlers are used to resume dialogs and process tokens.
    7. Respect per-user authorization in back-end systems
      • Once the bot has a user-specific token for a given system (for example, via OAuth 2.0), that token should be used to query Jira/Confluence or other systems so that only data the user is authorized to see is returned.
      • This avoids the problem of a single service account seeing everything and leaking data.
    8. Use other identity providers when needed
      • The bot framework and Teams SDK support other identity providers (for example, Facebook, GitHub, Google, Dropbox) via the same OAuth-based pattern.
      • For legacy systems (for example, LDAP or SAML-only apps), best practice is to front them with an identity provider or gateway that can issue OAuth 2.0 tokens, then integrate that provider with the bot’s OAuth configuration.

    Overall best practice: configure OAuth connections per resource, obtain per-user tokens via Azure Bot Service/Teams authentication flows, and use those tokens to call back-end systems. Avoid forwarding Teams tokens directly or using a single service account that bypasses per-user authorization.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.