使用者驗證

適用于: SDK v4

Bot 有時必須代表使用者存取受保護的線上資源,例如檢查電子郵件、檢查航班狀態或下訂單。 使用者必須授權 Bot 代表他們執行此動作,而且為了授權 Bot,使用者必須驗證其身分識別。 OAuth 可用來驗證使用者並授權 Bot。 另 請參閱驗證類型

如果您想要重新整理 OAuth 知識,請參閱下列內容:

交談中的使用者驗證

若要代表使用者執行特定作業,例如檢查電子郵件、參考行事曆、檢查航班狀態或下單,Bot 必須呼叫外部服務,例如 Microsoft Graph、GitHub 或公司的 REST 服務。 每個外部服務都有保護這些呼叫的方法。 發出這些要求的常見方法是使用使用者權杖 ,以唯一 識別該外部服務上的使用者(有時稱為 JSON Web 權杖 (JWT))。

若要保護外部服務的呼叫,Bot 必須要求使用者登入,才能取得該服務的使用者權杖。 許多服務都支援透過 OAuth OAuth2 通訊協定擷 取權杖。

Azure AI Bot 服務提供特殊的 登入 卡片和服務,可與 OAuth 通訊協定搭配運作,並管理權杖生命週期。 Bot 可以使用這些功能來取得使用者權杖。

  • 在 Bot 設定中, OAuth 連線 會在 Azure 中的 Azure AI Bot Service 資源內註冊。

    連線包含要使用的識別提供者 相關資訊 ,以及有效的 OAuth 用戶端識別碼和秘密、要啟用的 OAuth 範圍,以及該識別提供者所需的任何其他連線中繼資料。

  • 在 Bot 的程式碼中,OAuth 連線可用來協助登入使用者並取得使用者權杖。

下圖顯示驗證程式所涉及的元素。

Diagram illustrating the relationship between authentication components in Azure AI Bot Service.

關於 Bot Framework 權杖服務

Bot Framework 權杖服務負責:

  • 協助搭配各種外部服務使用 OAuth 通訊協定。
  • 安全地儲存特定 Bot、通道、交談和使用者的權杖。
  • 取得使用者權杖。

    提示

    如果 Bot 有過期的使用者權杖,Bot 應該:

    • 登出使用者
    • 再次起始登入流程

例如,可以使用 Microsoft Graph API 來檢查使用者最近電子郵件的 Bot 需要來自 識別提供者 的使用者權杖,在此案例 中為 Microsoft Entra ID 。 在設計階段,Bot 開發人員會執行這兩個重要步驟:

  1. 透過 Azure 入口網站 向 Bot Framework 權杖服務註冊 Microsoft Entra ID 應用程式、識別提供者。
  2. 設定 Bot 的 OAuth 連線(例如 GraphConnection ,命名為 )。

下圖顯示使用 Microsoft Graph 服務提出電子郵件要求時,使用者與 Bot 互動的時間順序。

Sequence diagram outlining the steps for a bot to send an email on behalf of a user.

  1. 使用者向 Bot 提出電子郵件要求。

  2. 具有此訊息的活動會從使用者傳送至 Bot Framework 通道服務。 通道服務可確保 userid 已設定活動內的欄位,並將訊息傳送至 Bot。

    注意

    使用者識別碼是特定通道,例如使用者的 Facebook 識別碼或其簡訊電話號碼。

  3. Bot 向 Bot Framework 權杖服務提出要求,詢問它是否已經有 OAuth 連線 GraphConnection 的 UserId 權杖。

  4. 由於這是此使用者第一次與 Bot 互動,因此 Bot Framework Token Service 還沒有此使用者的權杖,並將 NotFound 結果傳回 給 Bot。

    注意

    如果找到權杖,則會略過驗證步驟,而且 Bot 可以使用預存權杖提出電子郵件要求。

  5. Bot 會使用連線名稱 GraphConnection 建立 OAuthCard,並回復要求使用此卡片登入的使用者。

  6. 活動會通過 Bot Framework 通道服務,此服務會呼叫 Bot Framework 權杖服務,以為此要求建立有效的 OAuth 登入 URL。 此登入 URL 會新增至 OAuthCard,並將卡片傳回給使用者。

  7. 使用者會看到一則訊息,以按一下 OAuthCard 的登入按鈕來登入。

  8. 當使用者按一下登入按鈕時,通道服務會開啟網頁瀏覽器,並呼叫外部服務以載入其登入頁面。

  9. 使用者登入外部服務的此頁面。 然後,外部服務會完成與 Bot Framework Token Service 的 OAuth 通訊協定交換,導致外部服務將 Bot Framework 權杖服務傳送給使用者權杖。 Bot Framework 權杖服務會安全地儲存此權杖,並使用此權杖將活動傳送至 Bot。

  10. Bot 會使用權杖接收活動,並且能夠用它來對 MS Graph API 進行呼叫。

保護登入 URL

Bot Framework 有助於使用者登入時的重要考慮,就是如何保護登入 URL 的安全。 當使用者看到登入 URL 時,此 URL 會與該 Bot 的特定交談識別碼和使用者識別碼相關聯。 請勿共用此 URL,這會導致特定 Bot 交談發生錯誤的登入。 若要降低使用共用登入 URL 的安全性攻擊,請確定按一下登入 URL 的電腦和人員是擁有 交談視窗的人員

某些頻道,例如 Microsoft Teams、Direct Line 和 WebChat 都能夠執行這項操作,而不需要使用者注意到。 例如,WebChat 會使用會話 Cookie 來確保登入流程發生在與 WebChat 交談相同的瀏覽器中。 不過,對於其他通道,使用者通常會看到 6 位數 的魔術程式碼 。 這類似于內建的多重要素驗證,因為 Bot Framework 權杖服務不會將權杖釋放給 Bot,除非使用者完成最終驗證,證明登入的人員可以藉由輸入 6 位數的程式碼來存取聊天體驗。

重要

請記住這些重要的 安全性考慮 。 您可以在此部落格文章中找到其他資訊: 搭配 Azure AI Bot 服務驗證 使用 WebChat。

下一步

既然您已瞭解使用者驗證,讓我們來看看如何將它套用至您的 Bot。

另請參閱