使用者驗證User authentication

適用于: SDK v4APPLIES TO: SDK v4

有時 bot 必須代表使用者存取安全的線上資源,例如檢查電子郵件、檢查航班狀態或下訂單。At times a bot must access secured online resources on behalf of the user, such as checking email, checking on flight status, or placing an order. 使用者必須授權 bot 代表他們這麼做,為了授權 bot,使用者必須驗證他們的身分識別。The user must authorize the bot to do so on their behalf, and in order to authorize the bot, the user must authenticate their identity. OAuth 是用來驗證使用者及授權 bot。OAuth is used to authenticate the user and authorize the bot. 另請參閱 驗證類型See also Authentication types.

如果您想要重新整理您對 OAuth 的了解,請參閱下列資訊:If you want to refresh your OAuth knowledge, see the following:

對話中的使用者驗證User authentication in a conversation

若要代表使用者執行某些作業,例如檢查電子郵件、參考行事曆、查看航班狀態或下訂單,Bot 就會需要呼叫外部服務,例如 Microsoft Graph、GitHub 或公司的 REST 服務。To perform certain operations on behalf of a user, such as checking email, referencing a calendar, checking on flight status, or placing an order, the bot will need to call an external service, such as the Microsoft Graph, GitHub, or a company's REST service. 每個外部服務都會有可保護這些呼叫的方法。Each external service has a way of securing those calls. 用來發出這些要求的常見方法是使用「使用者權杖」 ,其可唯一識別該外部服務上的使用者 (有時也稱為 JSON Web 權杖 (JWT))。A common way to issue those requests is to use a user token that uniquely identifies the user on that external service (sometimes referred to as a JSON Web Token (JWT)).

為了保護以外部服務為目標的呼叫,Bot 必須要求使用者登入,讓其可以取得使用者的權杖來使用該服務。To secure the call to an external service, the bot must ask the user to sign-in, so it can acquire the user's token for that service. 許多服務支援透過 OAuthOAuth2 通訊協定來擷取權杖。Many services support token retrieval via the OAuth or OAuth2 protocol.

Azure Bot Service 提供特製化的 登入 卡片和服務,可搭配 OAuth 通訊協定使用及管理權杖生命週期。The Azure Bot Service provides specialized sign-in cards and services that work with the OAuth protocol and manage the token life-cycle. Bot 可以使用這些功能來取得使用者權杖。A bot can use these features to acquire a user token.

  • OAuth 連線 是 Bot 設定的一部分,其會註冊在 Azure 的 Azure Bot Service 資源中。As part of bot configuration, an OAuth connection is registered within the Azure Bot Service resource in Azure.

    連線內包含要使用的 身分識別提供者 相關資訊,以及有效的 OAuth 用戶端識別碼及祕密、要啟用的 OAuth 範圍和該身分識別提供者所需的任何其他連線中繼資料。The connection contains information about the identity provider to use, along with a valid OAuth client ID and secret, the OAuth scopes to enable, and any other connection metadata required by that identity provider.

  • 在 Bot 的程式碼中,OAuth 連線可用來協助登入使用者,並取得使用者權杖。In the bot's code, the OAuth connection is used to help sign-in the user and get the user token.

下圖顯示驗證程序所涉及的元素。The following image shows the elements involved in the authentication process.

Bot 驗證元件

關於 Bot Framework 權杖服務About the Bot Framework Token Service

Bot Framework 權杖服務負責下列事項:The Bot Framework Token Service is responsible for:

  • 促使 OAuth 通訊協定搭配各種不同外部服務使用。Facilitating the use of the OAuth protocol with a wide variety of external services.
  • 安全儲存特定 Bot、通道、對話及使用者的權杖。Securely storing tokens for a particular bot, channel, conversation, and user.
  • 取得使用者權杖。Acquiring user tokens.

    提示

    如果 Bot 的使用者權杖過期,應該會:If the bot has an expired user token, the bot should:

    • 登出使用者Log the user out
    • 再次起始登入流程Initiate the sign in flow again

例如,可以使用 Microsoft Graph API 檢查使用者最近電子郵件的 Bot 需要來自 身分識別提供者 的使用者權杖,此案例所用的權杖為 Azure Active DirectoryFor example, a bot that can check a user's recent emails, using the Microsoft Graph API, requires a user token from an Identity Provider, in this case Azure Active Directory. 在設計階段,Bot 開發人員會執行下列兩個重要步驟:At design time, the bot developer performs these two important steps:

  1. 透過 Azure 入口網站向 Bot Framework 權杖服務註冊 Azure Active Directory 應用程式 (此為身分識別提供者)。Registers an Azure Active Directory application, an Identity Provider, with the Bot Framework Token Service, via the Azure Portal.
  2. 設定 Bot 的 OAuth 連線 (例如 GraphConnection)。Configures an OAuth connection (named for example GraphConnection) for the bot.

下圖顯示使用 Microsoft Graph 服務提出電子郵件要求時,使用者與 Bot 互動的時間序列。The following picture shows the time sequence of the user's interaction with a bot when an email request is made using the Microsoft Graph service.

Bot 驗證時間序列

  1. 使用者向 Bot 提出電子郵件要求。The user makes an email request to the bot.

  2. 包含此訊息的活動會從使用者端傳送到 Bot Framework 通道服務。An activity with this message is sent from the user to the Bot Framework channel service. 通道服務可確保活動內的 userid 欄位已設定,並將訊息傳送到 Bot。The channel service ensures that the userid field within the activity has been set and the message is sent to the bot.

    注意

    使用者識別碼會專屬於各通道,例如使用者的 Facebook 識別碼或其 SMS 電話號碼。User ID's are channel specific, such as the user's Facebook ID or their SMS phone number.

  3. Bot 會對 Bot Framework 權杖服務發出要求,詢問其是否已有用於 OAuth 連線 GraphConnection 的 UserId 權杖。The bot makes a request to the Bot Framework Token Service asking if it already has a token for the UserId for the OAuth connection GraphConnection.

  4. 由於這是此使用者第一次與 Bot 互動,Bot Framework 權杖服務還沒有此使用者的權杖,因此會將 NotFound 的結果傳回給 Bot。Since this is the first time this user has interacted with the bot, the Bot Framework Token Service does not yet have a token for this user, and returns a NotFound result to the bot.

    注意

    如果有找到權杖就會略過驗證步驟,而且 Bot 可以使用儲存的權杖來提出電子郵件要求。If the token is found, the authentication steps are skipped and the bot can make the email request using the stored token.

  5. Bot 會以 GraphConnection 連線名稱建立 OAuthCard,並回覆使用者,要求其使用這張卡片登入。The bot creates an OAuthCard with a connection name of GraphConnection and replies to the user asking to sign-in using this card.

  6. 活動會透過 Bot Framework 通道服務傳遞,以呼叫 Bot Framework 權杖服務為此要求建立有效的 OAuth 登入 URL。The activity passes through the Bot Framework Channel Service, which calls into the Bot Framework Token Service to create a valid OAuth sign-in URL for this request. 此登入 URL 會新增至 OAuthCard,而該卡片會傳回給使用者。This sign-in URL is added to the OAuthCard and the card is returned to the user.

  7. 使用者會看到藉由按一下 OAuthCard 登入按鈕來登入的訊息。The user is presented with a message to sign-in by clicking on the OAuthCard's sign-in button.

  8. 當使用者按一下 [登入] 按鈕時,通道服務便會開啟網頁瀏覽器,以及呼叫外部服務來載入其登入頁面。When the user clicks the sign-in button, the channel service opens a web browser and calls out to the external service to load its sign-in page.

  9. 使用者會登入此頁面來使用外部服務。The user signs-in to this page for the external service. 然後,外部服務會完成 OAuth 通訊協定與 Bot Framework 權杖服務的交換,讓外部服務將使用者權杖傳送給 Bot Framework 權杖服務。Then the external service completes the OAuth protocol exchange with the Bot Framework Token Service, resulting in the external service sending the Bot Framework Token Service the user token. Bot Framework 權杖服務會安全地儲存此權杖,並以此權杖將活動傳送給 Bot。The Bot Framework Token Service securely stores this token and sends an activity to the bot with this token.

  10. Bot 會收到包含權杖的活動,並且使用該權杖來對 MS Graph API 進行呼叫。The bot receives the activity with the token and is able to use it to make calls against the MS Graph API.

保護登入 URLSecuring the sign-in URL

當 Bot Framework 促使使用者登入後,如何保護登入 URL 是重要的考量。An important consideration when the Bot Framework facilitates a user login is how to secure the sign-in URL. 當使用者看到登入 URL 時,此 URL 會與特定的對話識別碼和該 Bot 的使用者識別碼相關聯。When a user is presented with a sign-in URL, this URL is associated with a specific conversation ID and user ID for that bot. 此 URL 不得共用,因為這會造成特定 Bot 對話發生登入錯誤。This URL should not be shared, as it would cause the wrong sign-in to occur for a particular bot conversation. 若要減少與共用登入 URL 相關的安全性攻擊,必須確保按下登入 URL 的機器和人員是 擁有 對話視窗的人員。To mitigate security attacks regarding sharing the sign-in URL, it is necessary to ensure that the machine and person who clicks on the sign-in URL is the person who owns the conversation window.

某些通道(例如 Microsoft 小組、Direct Line 和 WebChat)可以在不察覺使用者的情況下進行。Some channels such as Microsoft Teams, Direct Line, and WebChat are able to do this without the user noticing. 例如,WebChat 會使用工作階段 Cookie 確保登入流程會在 WebChat 對話所在的瀏覽器中發生。For example, WebChat uses session cookies to ensure that the sign-in flow took place in the same browser as the WebChat conversation. 不過,針對其他通道,使用者通常會看到 6 位數的 神奇代碼However, for other channels the user is often presented with a 6-digit magic code. 這類似於內建的多重要素驗證,使用者必須完成最後的驗證,也就是輸入 6 位數代碼以證明登入的人員可存取聊天體驗後,Bot Framework 權杖服務才會將權杖釋放給 Bot。This is similar to a built-in multi-factor authentication, as the Bot Framework Token Service will not release the token to the bot unless the user finishes the final authentication, proving that the person who signed-in has access to the chat experience by entering the 6-digit code.

重要

請留意這些重要的安全性考量Please, keep in mind these important Security considerations. 您可以在此部落格文章中找到其他資訊:使用網路聊天搭配 Azure Bot Service 驗證You can find additional information in this blog post: Using WebChat with Azure Bot Service Authentication.

下一步Next steps

現在您已瞭解使用者驗證,讓我們看看如何將其套用至您的 bot。Now that you know about user authentication, let's take a look at how to apply that to your bot.

另請參閱See also