{"id":11389,"date":"2022-08-31T08:00:26","date_gmt":"2022-08-31T15:00:26","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/?p=11389"},"modified":"2022-08-31T08:00:26","modified_gmt":"2022-08-31T15:00:26","slug":"account-linking-with-microsoft-teams-single-sign-on","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/account-linking-with-microsoft-teams-single-sign-on\/","title":{"rendered":"Account linking with Microsoft Teams single sign-on"},"content":{"rendered":"

Have you had trouble understanding how to use single sign-on (SSO)? Are you trying to link your identity system with Teams SSO for your Teams app? In this article, learn what Teams single sign-on means and take a look at a sample we\u2019ve built to help you use Teams SSO with your Identity Provider (IDP).<\/p>\n

Before we dive into these details, it\u2019s important to understand how to link user accounts between Teams and your app and Teams SSO.\nThe following resources are recommended to review:<\/p>\n

    \n
  1. Learn about single sign-on in Azure Active Directory<\/a><\/li>\n
  2. Learn about single sign-on in Teams<\/a><\/li>\n
  3. Complete this Teams SSO tutorial on Microsoft Learn<\/a><\/li>\n
  4. Use this sample to deploy SSO in Teams<\/a><\/li>\n
  5. (New!) Use our sample for deploying SSO in Teams with your app\/IDP and perform account linking<\/a><\/li>\n<\/ol>\n

    You can also learn with this series of hands-on labs in Microsoft Teams App Camp<\/a>, which leads you through the experience of turning a simple web application into a Microsoft Teams application. As part of these labs, an account linking strategy is used to allow users to log in with Azure Active Directory SSO and still maintain user profiles and authorization from the original identity provider.<\/p>\n

    Teams SSO Overview<\/h2>\n

    In short, Teams SSO is an identification model that enables users to login into a Microsoft Teams application with the same credentials they used when they signed into Microsoft Teams. The process is completely silent unless the application needs to ask the user to grant additional permissions. This diagram helps illustrate the underlying mechanism.<\/p>\n

    \"diagram<\/a><\/p>\n

     <\/p>\n

    For a longer explanation of SSO, please refer to this article: Let\u2019s decode: Single Sign-on in Microsoft Teams tabs – Microsoft 365 Developer Blog<\/a> and follow this Teams SSO tutorial on Microsoft Learn: Microsoft Teams \u2013 Authentication and Single Sign-on – Learn | Microsoft Docs<\/a><\/p>\n

    What are the challenges?<\/h2>\n

    Teams SSO<\/a>\u00a0offers a seamless experience for partners to build auth inside of Teams. However, Teams SSO can be difficult to implement when you (the person building the Teams app) need to link user accounts between Teams and your app’s identity systems.<\/p>\n

    To get around this, we typically see partners try to use email addresses to match up user identities in their different systems. However, that generates several problems.<\/p>\n

    Even if the emails are the same, there are a few problems. First, emails and User Principal Names (UPNs) can sometimes change. Second, most likely, the identity framework you’ve chosen won’t accept a simple email mapping and provide the user’s access tokens in their system. These access tokens are required because they are used to get permissions on the user’s behalf and are extremely important to keep secure. This path would also require you to change your own security architecture to allow special requests from your Teams apps.<\/p>\n

    This is especially difficult if the user’s email in Teams is different than their email in your system. For example, the user\u2019s AAD email could be:\u00a0john@contoso.com<\/a>, but the email that is registered with you is\u00a0john@gmail.com<\/a>\u00a0or even\u00a0johnmatthews@contoso.com<\/a>. In both of these examples, the emails don\u2019t match up. The personal email address issue occurs frequently with apps that exist outside of enterprise scope.<\/p>\n

    There’s an elegant solution to this problem.<\/p>\n

    An elegant solution<\/h2>\n

    Description<\/h3>\n
      \n
    1. Get the user’s AAD access token – which can be done with a simple call (the beauty of SSO – review SSO Overview if this is unclear)<\/li>\n
    2. Ask the user to sign into your chosen system or Identity Provider (IDP)<\/li>\n
    3. Retrieve the access that your system or the Identity Provider provides<\/li>\n
    4. Store that access token in a table associated with the user’s AAD identity<\/li>\n<\/ol>\n

      Therefore, there are four parts to this solution:<\/p>\n