Share via

Användarautentisering

  • Artikel

GÄLLER FÖR: SDK v4

Ibland måste en robot komma åt skyddade onlineresurser för användarens räkning, till exempel kontrollera e-post, kontrollera flygstatus eller göra en beställning. Användaren måste auktorisera roboten för deras räkning, och för att kunna auktorisera roboten måste användaren autentisera sin identitet. OAuth används för att autentisera användaren och auktorisera roboten. Se även Autentiseringstyper.

Om du vill uppdatera dina OAuth-kunskaper kan du läsa följande:

Användarautentisering i en konversation

För att utföra vissa åtgärder för en användares räkning, till exempel att kontrollera e-post, referera till en kalender, kontrollera flygstatus eller göra en beställning, måste roboten anropa en extern tjänst, till exempel Microsoft Graph, GitHub eller ett företags REST-tjänst. Varje extern tjänst har ett sätt att skydda dessa anrop. Ett vanligt sätt att utfärda dessa begäranden är att använda en användartoken som unikt identifierar användaren på den externa tjänsten (kallas ibland för en JSON-webbtoken (JWT)).

För att skydda anropet till en extern tjänst måste roboten be användaren att logga in, så att den kan hämta användarens token för tjänsten. Många tjänster stöder tokenhämtning via OAuth - eller OAuth2-protokollet .

Azure AI Bot Service tillhandahåller specialiserade inloggningskort och tjänster som fungerar med OAuth-protokollet och hanterar tokens livscykel. En robot kan använda dessa funktioner för att hämta en användartoken.

  • Som en del av robotkonfigurationen registreras en OAuth-anslutning i Azure AI Bot Service-resursen i Azure.

    Anslutningen innehåller information om identitetsprovidern som ska användas, tillsammans med ett giltigt OAuth-klient-ID och hemlighet, OAuth-omfång som ska aktiveras och eventuella andra anslutningsmetadata som krävs av identitetsprovidern.

  • I robotens kod används OAuth-anslutningen för att logga in på användaren och hämta användartoken.

Följande bild visar de element som ingår i autentiseringsprocessen.

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

Om Bot Framework-tokentjänsten

Bot Framework-tokentjänsten ansvarar för:

  • Underlätta användningen av OAuth-protokollet med en mängd olika externa tjänster.
  • Lagra token på ett säkert sätt för en viss robot, kanal, konversation och användare.
  • Hämtar användartoken.

    Dricks

    Om roboten har en användartoken som har upphört att gälla bör roboten:

    • Logga ut användaren
    • Initiera inloggningsflödet igen

En robot som kan kontrollera en användares senaste e-postmeddelanden med hjälp av Microsoft Graph API kräver till exempel en användartoken från en identitetsprovider, i det här fallet Microsoft Entra-ID. Vid designtillfället utför robotutvecklaren dessa två viktiga steg:

  1. Registrerar ett Microsoft Entra-ID-program, en identitetsprovider, med Bot Framework Token Service via Azure-portalen.
  2. Konfigurerar en OAuth-anslutning (med namnet till exempel GraphConnection) för roboten.

Följande bild visar tidssekvensen för användarens interaktion med en robot när en e-postbegäran görs med hjälp av Microsoft Graph-tjänsten.

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

  1. Användaren skickar en e-postbegäran till roboten.

  2. En aktivitet med det här meddelandet skickas från användaren till Bot Framework-kanaltjänsten. Kanaltjänsten ser till att fältet userid i aktiviteten har angetts och att meddelandet skickas till roboten.

    Kommentar

    Användar-ID:n är kanalspecifika, till exempel användarens Facebook-ID eller deras SMS-telefonnummer.

  3. Roboten skickar en begäran till Bot Framework Token Service och frågar om den redan har en token för UserId för OAuth-anslutningen GraphConnection.

  4. Eftersom det är första gången den här användaren interagerar med roboten har Bot Framework Token Service ännu ingen token för den här användaren och returnerar ett NotFound-resultat till roboten.

    Kommentar

    Om token hittas hoppas autentiseringsstegen över och roboten kan göra e-postbegäran med hjälp av den lagrade token.

  5. Roboten skapar ett OAuthCard med anslutningsnamnet GraphConnection och svarar användaren som ber om att logga in med det här kortet.

  6. Aktiviteten passerar via Bot Framework Channel Service, som anropar Bot Framework Token Service för att skapa en giltig OAuth-inloggnings-URL för den här begäran. Den här inloggnings-URL:en läggs till i OAuthCard och kortet returneras till användaren.

  7. Användaren får ett meddelande om att logga in genom att klicka på OAuthCards inloggningsknapp.

  8. När användaren klickar på inloggningsknappen öppnar kanaltjänsten en webbläsare och anropar den externa tjänsten för att läsa in inloggningssidan.

  9. Användaren loggar in på den här sidan för den externa tjänsten. Sedan slutför den externa tjänsten OAuth-protokollutbytet med Bot Framework Token Service, vilket resulterar i att den externa tjänsten skickar Bot Framework Token Service till användartoken. Bot Framework Token Service lagrar den här token på ett säkert sätt och skickar en aktivitet till roboten med den här token.

  10. Roboten tar emot aktiviteten med token och kan använda den för att göra anrop mot MS Graph-API:et.

Skydda inloggnings-URL:en

Ett viktigt övervägande när Bot Framework underlättar en användarinloggning är hur du skyddar inloggnings-URL:en. När en användare får en inloggnings-URL associeras den här URL:en med ett specifikt konversations-ID och användar-ID för roboten. Dela inte den här URL:en– det skulle orsaka fel inloggning för en viss robotkonversation. För att undvika säkerhetsattacker som använder en delad inloggnings-URL kontrollerar du att den dator och person som klickar på inloggnings-URL:en är den person som äger konversationsfönstret.

Vissa kanaler som Microsoft Teams, Direct Line och WebChat kan göra detta utan att användaren märker det. WebChat använder till exempel sessionscookies för att säkerställa att inloggningsflödet ägde rum i samma webbläsare som WebChat-konversationen. Men för andra kanaler visas användaren ofta med en 6-siffrig magisk kod. Detta liknar en inbyggd multifaktorautentisering, eftersom Bot Framework Token Service inte släpper token till roboten om inte användaren slutför den slutliga autentiseringen, vilket bevisar att personen som loggade in har åtkomst till chattupplevelsen genom att ange den 6-siffriga koden.

Viktigt!

Tänk på dessa viktiga säkerhetsöverväganden. Du hittar ytterligare information i det här blogginlägget: Använda WebChat med Azure AI Bot Service Authentication.

Nästa steg

Nu när du vet om användarautentisering ska vi ta en titt på hur du tillämpar det på din robot.

Lägga till autentisering i en robot

Se även