Share via

Single sign mit einem Webchat

  • Artikel

GILT FÜR: SDK v4

Einmaliges Anmelden (Single Sign-On, SSO) ermöglicht es einem Client, z. B. einer Web-Chat-Steuerung, im Namen des Benutzers mit einem Bot oder Skill zu kommunizieren. Aktuell wird nur der Identitätsanbieter Microsoft Entra ID unterstützt.

In der Regel wird ein Webchat in eine Websiteseite eingebettet. Wenn sich der Benutzer bei der Website anmeldet, ruft der Webchat einen Bot im Namen des Benutzers auf. Das Token des Website-Clients, das auf den Anmeldedaten des Nutzers basiert, wird gegen ein anderes Token ausgetauscht, um auf den Bot zuzugreifen. Auf diese Weise muss sich der Benutzer nicht zweimal anmelden; das erste Mal auf der Website und das zweite Mal auf dem Bot, daher der Begriff SSO.

Das folgende Diagramm zeigt den SSO-Flow bei Verwendung eines Webchat-Clients.

Sequence diagram for sign-on flow for Web Chat.

Im Falle eines Fehlers greift SSO auf das ursprüngliche Verhalten zurück und zeigt die OAuth-Karte an. Fehler können auftreten, wenn die Benutzereinwilligung erforderlich ist oder wenn der Token-Exchange fehlschlägt.

Sehen wir uns den Ablauf etwas genauer an.

  1. Der Benutzer meldet sich bei der Website an.

  2. Eine OAuth-Triggeraktivität wird vom Webchat empfangen.

  3. Der Webchat startet eine Unterhaltung mit dem Bot über eine OAuth-Triggeraktivität.

  4. Der Bot gibt eine OAuth-Karte an den Webchat zurück.

  5. Der Webchat fängt die OAuth-Karte ab, bevor sie dem Benutzer angezeigt wird, und überprüft, ob sie eine Eigenschaft vom Typ TokenExchangeResource enthält.

  6. Wenn die Eigenschaft vorhanden ist, muss der Webchat ein austauschbares Token für den Benutzer abrufen, das ein Microsoft-Entra-ID-Token sein muss.

  7. Der Webchat sendet eine Aufrufaktivität (Invoke) mit dem unten gezeigten Text an den Bot.

    {
    "type": "Invoke",
    "name": "signin/tokenExchange",
    "value": {
        "id": "<any unique ID>",
        "connectionName": "<connection name on the bot (from the OAuth Card)>",
        "token": "<exchangeable token>"
    }
}

  8. Der Bot verarbeitet das TokenExchangeInvokeRequest, indem er eine Anforderung an den Azure KI Bot Service sendet, um ein austauschbares Token zu erhalten.

  9. Der Azure KI Bot Service sendet das Token an den Bot.

  10. Der Bot sendet ein TokenExchangeInvokeResponse zurück an den Webchat. Der Webchat wartet, bis er das TokenExchangeInvokeResponse erhält.

    {
    "status": "<response code>",
    "body": {
        "id":"<unique ID>",
        "connectionName": "<connection Name on the bot (from the OAuth Card)>",
        "failureDetail": "<failure reason if status code isn't 200, null otherwise>"
    }
}

  11. Wenn das TokenExchangeInvokeResponse ein status von 200 hat, dann zeigt der Webchat die OAuth-Karte nicht an. Bei jedem anderen status oder wenn das TokenExchangeInvokeResponse nicht empfangen wird, zeigt der Webchat dem Benutzer die OAuth-Karte an. Dadurch wird sichergestellt, dass der SSO-Ablauf auf den normalen OAuthCard-Ablauf ausweicht, wenn ein Fehler auftritt oder Abhängigkeiten wie etwa die Benutzereinwilligung nicht erfüllt sind.

Ein Implementierungsbeispiel finden Sie in diesem SSO-Beispiel.