Freigeben über

Authentifizierung mit der Bot Connector-API

  • Artikel

Ihr Bot kommuniziert mit dem Bot Connector-Dienst über HTTP über einen sicheren Kanal (SSL/TLS). Wenn Ihr Bot eine Anforderung an den Connector-Dienst sendet, muss diese Informationen enthalten, anhand derer der Connector-Dienst die Identität bestätigen kann. Ebenso muss der Connector-Dienst, wenn er eine Anforderung an Ihren Bot sendet, Informationen enthalten, anhand der Bot die Identität überprüfen kann. In diesem Artikel werden die Authentifizierungstechnologien und die Anforderungen für Authentifizierung auf Dienstebene beschrieben, die zwischen einem Bot und dem Bot Connector-Dienst erfolgt. Wenn Sie eigenen Authentifizierungscode schreiben, müssen Sie die in diesem Artikel beschriebenen Sicherheitsverfahren implementieren, um Ihrem Bot den Austausch von Nachrichten mit dem Bot Connector-Dienst zu ermöglichen.

Wichtig

Wenn Sie eigenen Authentifizierungscode schreiben, ist es wichtig, dass alle Sicherheitsverfahren ordnungsgemäß implementiert werden. Durch die Implementierung aller Schritte in diesem Artikel können Sie das Risiko verringern, dass ein Angreifer in der Lage ist, Nachrichten zu lesen, die an Ihren Bot gesendet werden, Nachrichten zu senden, die sich als Ihr Bot ausgeben, und geheime Schlüssel zu stehlen.

Wenn Sie das Bot Framework SDK verwenden, müssen Sie die in diesem Artikel beschriebenen Sicherheitsverfahren nicht implementieren, da das SDK dies automatisch für Sie erledigt. Konfigurieren Sie einfach Ihr Projekt mit der für Ihren Bot während der Registrierung erhaltenen App-ID und dem Kennwort, und das SDK erledigt den Rest.

Authentifizierungstechnologien

Vier Authentifizierungstechnologien werden verwendet, um eine Vertrauensstellung zwischen einem Bot und dem Bot Connector herzustellen:

Technologie Beschreibung
SSL/TLS SSL/TLS wird für alle Verbindungen von Dienst zu Dienst verwendet. X.509v3-Zertifikate werden verwendet, um die Identität aller HTTPS-Dienste festzustellen. Clients sollten Dienstzertifikate immer überprüfen, um sicherzustellen, dass sie vertrauenswürdig und gültig sind. (Clientzertifikate werden NICHT als Teil dieses Schema verwendet.)
OAuth 2.0 OAuth 2.0 verwendet den Microsoft Entra ID-Kontoanmeldungsdienst, um ein sicheres Token zu erzeugen, das ein Bot zum Senden von Nachrichten verwenden kann. Dieses Token ist ein Dienst-zu-Dienst-Token. Es ist keine Benutzeranmeldung erforderlich.
JSON Web Token (JWT) JSON Web Token werden verwendet, um Token zu codieren, die vom und an den Bot gesendet werden. Clients sollten alle empfangenen JWT-Token vollständig gemäß den in diesem Artikel beschriebenen Anforderungen überprüfen.
OpenID-Metadaten Der Bot Connector-Dienst veröffentlicht eine Liste mit gültigen Token, die zum Signieren der eigenen JWT-Token verwendet, in OpenID-Metadaten auf einem bekannten statischen Endpunkt.

In diesem Artikel wird beschrieben, wie Sie diese Technologien über Standard-HTTPS und -JSON verwenden können. Es werden keine speziellen SDKs benötigt, obwohl Sie vielleicht feststellen, dass Helfer für OpenID und andere nützlich sind.

Authentifizieren von Anforderungen von Ihrem Bot an den Bot Connector-Dienst

Um mit dem Bot Connector-Dienst zu kommunizieren, müssen Sie ein Zugriffstoken im Authorization-Header jeder API-Anforderung unter Verwendung dieses Formats angeben:

Authorization: Bearer ACCESS_TOKEN

So erhalten und verwenden Sie ein JWT-Token für Ihren Bot:

  1. Ihr Bot sendet eine GET-HTTP-Anforderung an den MSA-Anmeldedienst.
  2. Die Antwort des Dienstes enthält das zu verwendende JWT-Token.
  3. Ihr Bot enthält dieses JWT-Token im Autorisierungsheader in Anforderungen an den Bot Connector-Dienst.

Schritt 1: Fordern Sie ein Zugriffstoken vom Kontoanmeldedienst von Microsoft Entra ID an

Wichtig

Falls nicht bereits geschehen, müssen Sie Ihren Bot bei Bot Framework registrieren, um dessen AppID und Kennwort zu erhalten. Sie benötigen die App-ID und das Kennwort des Bots, um ein Zugriffstoken anzufordern.

Ihre Bot-Identität kann in Azure auf verschiedene Arten verwaltet werden.

  • Als eine benutzerseitig zugewiesene verwaltete Identität, damit Sie die Anmeldedaten des Bots nicht selbst verwalten müssen.
  • Als einzelinstanzfähige Anwendung.
  • Als eine mehrinstanzenfähige App.

Fordern Sie ein Zugriffstoken basierend auf dem Anwendungstyp Ihres Bots an.

Um ein Zugriffstoken vom Anmeldedienst anzufordern, führen Sie die folgende Anforderung aus, wobei Sie MICROSOFT-APP-ID und MICROSOFT-APP-PASSWORD durch die Angaben für die App-ID und das Kennwort des Bots ersetzen, die Sie beim Registrieren Ihres Bots beim Botdienst erhalten haben.

POST https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MICROSOFT-APP-ID&client_secret=MICROSOFT-APP-PASSWORD&scope=https%3A%2F%2Fapi.botframework.com%2F.default

Schritt 2: Abrufen des JWT-Tokens aus der Kontoanmeldungsdienstantwort von Microsoft Entra ID

Wenn Ihre Anwendung durch den Anmeldedienst autorisiert wurde, sind im JSON-Antworttext Ihr Zugriffstoken, sein Typ und sein Ablauf (in Sekunden) angegeben.

Wenn Sie das Token zum Authorization-Header einer Anforderung hinzufügen, müssen Sie genau den Wert verwenden, der in dieser Antwort angegeben ist – der Tokenwert darf nicht mit Escapezeichen versehen oder kodiert werden. Das Zugriffstoken ist bis zu seinem Ablauf gültig. Um zu verhindern, dass das Ablaufen von Token die Leistung Ihres Bots beeinträchtigt, können Sie das Token zwischenspeichern und proaktiv aktualisieren.

Im folgenden Beispiel wird eine Antwort vom Anmeldedienst für das Microsoft Entra ID-Konto gezeigt:

HTTP/1.1 200 OK
... (other headers)

{
    "token_type":"Bearer",
    "expires_in":3600,
    "ext_expires_in":3600,
    "access_token":"eyJhbGciOiJIUzI1Ni..."
}

Schritt 3: Angeben des JWT-Tokens im Autorisierungsheader von Anforderungen

Wenn Sie eine API-Anforderung an den Bot Connector-Dienst senden, geben Sie das Zugriffstoken im Authorization-Header der Anforderung unter Verwendung dieses Formats an:

Authorization: Bearer ACCESS_TOKEN

Alle Anforderungen, die Sie an den Bot Connector-Dienst senden, müssen das Zugriffstoken im Authorization-Header enthalten. Wenn das Token ist richtig formatiert ist, nicht abgelaufen ist und durch den Anmeldedienst für das Microsoft Entra ID-Konto generiert wurde, autorisiert der Bot Connector-Dienst die Anforderung. Zusätzliche Überprüfungen werden ausgeführt, um sicherzustellen, dass das Token zum Bot gehört, der die Anforderung gesendet hat.

Im folgenden Beispiel wird gezeigt, wie das Zugriffstoken im Authorization-Header der Anforderung angegeben wird.

POST https://smba.trafficmanager.net/teams/v3/conversations/12345/activities
Authorization: Bearer eyJhbGciOiJIUzI1Ni...

(JSON-serialized Activity message goes here)

Wichtig

Geben Sie das JWT-Token nur im Authorization-Header von Anforderungen an, die Sie an den Bot Connector-Dienst senden. Senden Sie das Token NICHT über unsichere Kanäle, und fügen Sie es NICHT in HTTP-Anforderungen ein, die Sie an andere Dienste senden. Das JWT-Token, das Sie vom Anmeldedienst für das Microsoft Entra ID-Konto erhalten, gleicht einem Kennwort und sollte mit äußerster Sorgfalt behandelt werden. Jeder, der in den Besitz des Tokens kommt, kann es zum Ausführen von Vorgängen im Namen Ihres Bots verwenden.

Bot an Connector: Beispiel für JWT-Komponenten

header:
{
  typ: "JWT",
  alg: "RS256",
  x5t: "<SIGNING KEY ID>",
  kid: "<SIGNING KEY ID>"
},
payload:
{
  aud: "https://api.botframework.com",
  iss: "https://sts.windows.net/d6d49420-f39b-4df7-a1dc-d59a935871db/",
  nbf: 1481049243,
  exp: 1481053143,
  appid: "<YOUR MICROSOFT APP ID>",
  ... other fields follow
}

Hinweis

Die tatsächlichen Felder können in der Praxis variieren. Erstellen und überprüfen Sie alle JWT-Token wie oben angegeben.

Authentifizieren von Anforderungen vom Bot Connector-Dienst an Ihren Bot

Wenn der Bot Connector-Dienst eine Anforderung an Ihren Bot sendet, wird ein signiertes JWT-Token im Authorization-Header der Anforderung angegeben. Ihr Bot kann Aufrufe des Bot Connector-Diensts authentifizieren, indem er die Echtheit des signierten JWT-Tokens überprüft.

Zum Authentifizieren von Aufrufen vom Bot Connector-Dienst:

  1. Ihr Bot erhält das JWT-Token aus dem Autorisierungsheader der vom Bot Connector-Dienst gesendeten Anfragen.
  2. Ihr Bot ruft das OpenID-Metadatendokument für den Bot Connector-Dienst ab.
  3. Ihr Bot ruft die Liste der gültigen Signaturschlüssel aus dem Dokument ab.
  4. Ihr Bot überprüft die Authentizität des JWT-Tokens.

Schritt 2: Abrufen des OpenID-Metadatendokuments

Das OpenID-Metadatendokument gibt den Speicherort eines zweiten Dokuments an, in dem die gültigen Signaturschlüssel des Bot Connector-Diensts auflistet sind. Um das OpenID-Metadatendokument zu erhalten, geben Sie diese Anforderung über HTTPS aus:

GET https://login.botframework.com/v1/.well-known/openidconfiguration

Tipp

Dies ist eine statische URL, die Sie in Ihrer Anwendung hartcodieren können.

Im folgenden Beispiel wird ein OpenID-Metadatendokument gezeigt, das als Antwort auf die GET-Anforderung zurückgegeben wird. Die jwks_uri-Eigenschaft gibt den Speicherort des Dokuments an, das die gültigen Signaturschlüssel des Bot Connector-Diensts enthält.

{
    "issuer": "https://api.botframework.com",
    "authorization_endpoint": "https://invalid.botframework.com",
    "jwks_uri": "https://login.botframework.com/v1/.well-known/keys",
    "id_token_signing_alg_values_supported": [
      "RS256"
    ],
    "token_endpoint_auth_methods_supported": [
      "private_key_jwt"
    ]
}

Schritt 3: Abrufen der Liste der gültigen Signaturschlüssel

Um die Liste der gültigen Signaturschlüssel zu erhalten, geben Sie eine GET-Anforderung über HTTPS an die von der jwks_uri-Eigenschaft im OpenID-Metadatendokument angegebene URL aus. Beispiel:

GET https://login.botframework.com/v1/.well-known/keys

Der Antworttext gibt das Dokument im JWK-Format an, enthält jedoch auch eine zusätzliche Eigenschaft für jeden Schlüssel: endorsements.

Tipp

Die Liste der Schlüssel ist stabil und kann zwischengespeichert werden, aber es können jederzeit neue Schlüssel hinzugefügt werden. Um sicherzustellen, dass Ihr Bot über eine aktuelle Kopie des Dokuments verfügt, bevor diese Schlüssel verwendet werden, sollten alle Bot-Instancen den lokalen Cache des Dokuments mindestens einmal alle 24 Stunden aktualisieren.

Die endorsements-Eigenschaft in jedem Schlüssel enthält eine oder mehrere Endorsement-Zeichenfolgen, mit denen Sie sicherstellen können, dass die in der channelId-Eigenschaft im Activity-Objekt angegebene Kanal-ID der eingehenden Anforderung echt ist. Die Liste der Kanal-IDs, die Endorsements erfordern, kann in jedem Bot konfiguriert werden. Standardmäßig ist es die Liste aller veröffentlichten Kanal-IDs, aber Botentwickler können bestimmte Kanal-ID-Werde in beiden Fällen überschreiben.

Schritt 4: Überprüfen des JWT-Tokens

Um die Echtheit des Tokens, das vom Bot Connector-Dienst gesendet wurde, zu überprüfen, müssen Sie das Token aus dem Authorization-Header der Anforderung extrahieren, das Token analysieren, seinen Inhalt überprüfen und seine Signatur überprüfen.

JWT-Analysebibliotheken sind für viele Plattformen verfügbar, und die meisten implementieren sichere und zuverlässige Analyse für JWT-Token. Allerdings müssen Sie diese Bibliotheken typischerweise so konfigurieren, dass bestimmte Eigenschaften des Tokens (Herausgeber, Zielgruppe usw.) korrekte Werte enthalten. Wenn Sie Token analysieren möchten, müssen Sie die Analysebibliothek konfigurieren oder eine eigene Überprüfung schreiben, um sicherzustellen, dass das Token diese Anforderungen erfüllt:

  1. Das Token wurde im HTTP Authorization-Header mit dem „Bearer“-Schema gesendet.
  2. Das Token liegt in gültigem, mit dem JWT-Standard konformen JSON-Format vor.
  3. Das Token enthält einen „issuer“-Anspruch mit dem https://api.botframework.com-Wert.
  4. Das Token enthält einen „audience“-Anspruchs mit einem Wert, der der Microsoft App-ID des Bots entspricht.
  5. Die Gültigkeit des Tokens ist nicht abgelaufen. Branchenstandard-Uhrabweichung beträgt 5 Minuten.
  6. Das Token verfügt über eine gültige kryptographische Signatur mit einem Schlüssel, der im OpenID-Schlüsseldokument aufgeführt ist, das in Schritt 3 abgerufen wurde, und verwendet einen Signaturalgorithmus, der in der id_token_signing_alg_values_supported-Eigenschaft des in Schritt 2 abgerufenen Open ID-Metadatendokuments angegeben ist.
  7. Das Token enthält einen Anspruch vom Typ „serviceUrl“ mit einem Wert, der der serviceUrl-Eigenschaft im Stamm des Activity-Objekts der eingehenden Anforderung entspricht.

Wenn das Endorsement für eine Kanal-ID erforderlich ist:

  • Legen Sie fest, dass jedes Activity-Objekt, das mit dieser Kanal-ID an Ihren Bot gesendet wird, zudem über ein JWT-Token verfügen muss, das mit einem Endorsement für diesen Kanal signiert ist.
  • Wenn kein Endorsement vorhanden ist, sollte Ihr Bot die Anforderung unter Rückgabe eines HTTP 403 (Unzulässig)-Statuscodes abweisen.

Wichtig

Alle diese Anforderungen sind wichtig, besonders die Anforderungen 4 und 6. Wenn nicht ALLE diese Verifizierungsanforderungen implementiert werden, ist der Bot offen für Angriffe, die dazu führen könnten, dass der Bot sein JWT-Token preisgibt.

Implementierer sollten keine Möglichkeit bieten, die Validierung des an den Bot gesendeten JWT-Tokens zu deaktivieren.

Connector an Bot: Beispiel für JWT-Komponenten

header:
{
  typ: "JWT",
  alg: "RS256",
  x5t: "<SIGNING KEY ID>",
  kid: "<SIGNING KEY ID>"
},
payload:
{
  aud: "<YOU MICROSOFT APP ID>",
  iss: "https://api.botframework.com",
  nbf: 1481049243,
  exp: 1481053143,
  ... other fields follow
}

Hinweis

Die tatsächlichen Felder können in der Praxis variieren. Erstellen und überprüfen Sie alle JWT-Token wie oben angegeben.

Authentifizieren von Anforderungen vom Bot Framework Emulator an Ihren Bot

Der Bot Framework Emulator ist ein Desktoptool, das Sie zum Testen der Funktionalität Ihres Bots verwenden können. Der Bot Framework Emulator verwendet zwar die gleichen Authentifizierungstechnologien wie oben beschrieben, ist aber nicht in der Lage, den echten Bot Connector-Dienst nachzuahmen. Stattdessen verwendet er die Microsoft App-ID und das Microsoft App-Kennwort, die Sie angeben, wenn Sie den Emulator mit Ihrem Bot verbinden, um Token zu erstellen, die mit denen identisch sind, die der Bot erstellt. Wenn der Emulator eine Anforderung an Ihren Bot sendet, wird das JWT-Token im Authorization-Header der Anforderung angegeben – im Wesentlichen mit den eigenen Anmeldeinformationen des Bots zum Authentifizieren der Anforderung.

Wenn Sie eine Authentifizierungsbibliothek implementieren und Anforderungen vom Bot Framework-Emulator akzeptiert werden sollen, müssen Sie diesen zusätzlichen Überprüfungspfad hinzufügen. Der Pfad gleicht in der Struktur dem Connector -> Bot-Überprüfungspfad, verwendet jedoch das OpenID-Dokument des MSA anstelle des Bot Connector-OpenID-Dokuments.

Zum Authentifizieren von Aufrufen vom Bot Framework Emulator:

  1. Ihr Bot erhält das JWT-Token aus dem Autorisierungsheader der vom Bot Framework Emulator gesendeten Anfragen.
  2. Ihr Bot ruft das OpenID-Metadatendokument für den Bot Connector-Dienst ab.
  3. Ihr Bot ruft die Liste der gültigen Signaturschlüssel aus dem Dokument ab.
  4. Ihr Bot überprüft die Authentizität des JWT-Tokens.

Schritt 2: Abrufen des MSA OpenID-Metadatendokuments

Das OpenID-Metadatendokument gibt den Speicherort eines zweiten Dokuments an, in dem die gültigen Signaturschlüssel auflistet sind. Um das MSA OpenID-Metadatendokument zu erhalten, geben Sie diese Anforderung über HTTPS aus:

GET https://login.microsoftonline.com/botframework.com/v2.0/.well-known/openid-configuration

Im folgenden Beispiel wird ein OpenID-Metadatendokument gezeigt, das als Antwort auf die GET-Anforderung zurückgegeben wird. Die jwks_uri-Eigenschaft gibt den Speicherort des Dokuments an, das die gültigen Signaturschlüssel enthält.

{
    "authorization_endpoint":"https://login.microsoftonline.com/common/oauth2/v2.0/authorize",
    "token_endpoint":"https://login.microsoftonline.com/common/oauth2/v2.0/token",
    "token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt"],
    "jwks_uri":"https://login.microsoftonline.com/common/discovery/v2.0/keys",
    ...
}

Schritt 3: Abrufen der Liste der gültigen Signaturschlüssel

Um die Liste der gültigen Signaturschlüssel zu erhalten, geben Sie eine GET-Anforderung über HTTPS an die von der jwks_uri-Eigenschaft im OpenID-Metadatendokument angegebene URL aus. Beispiel:

GET https://login.microsoftonline.com/common/discovery/v2.0/keys
Host: login.microsoftonline.com

Der Antworttext gibt das Dokument im JWK-Format an.

Schritt 4: Überprüfen des JWT-Tokens

Um die Echtheit des Tokens, das vom Emulator gesendet wurde, zu überprüfen, müssen Sie das Token aus dem Authorization-Header der Anforderung extrahieren, das Token analysieren, seinen Inhalt überprüfen und seine Signatur überprüfen.

JWT-Analysebibliotheken sind für viele Plattformen verfügbar, und die meisten implementieren sichere und zuverlässige Analyse für JWT-Token. Allerdings müssen Sie diese Bibliotheken typischerweise so konfigurieren, dass bestimmte Eigenschaften des Tokens (Herausgeber, Zielgruppe usw.) korrekte Werte enthalten. Wenn Sie Token analysieren möchten, müssen Sie die Analysebibliothek konfigurieren oder eine eigene Überprüfung schreiben, um sicherzustellen, dass das Token diese Anforderungen erfüllt:

  1. Das Token wurde im HTTP Authorization-Header mit dem „Bearer“-Schema gesendet.
  2. Das Token liegt in gültigem, mit dem JWT-Standard konformen JSON-Format vor.
  3. Das Token enthält einen „issuer“-Anspruch mit einem der hervorgehobenen Werte für nichtstaatliche Fälle. Durch Überprüfen auf beide „issuer“-Werte wird sichergestellt, dass Sie die „issuer“-Werte sowohl für das Sicherheitsprotokoll der Version 3.1 als auch der Version 3.2 prüfen.
  4. Das Token enthält einen „audience“-Anspruchs mit einem Wert, der der Microsoft App-ID des Bots entspricht.
  5. Der Emulator sendet abhängig von der Version die AppId entweder über den Appid-Anspruch (Version 1) oder den Anspruch der autorisierten Partei (Version 2).
  6. Die Gültigkeit des Tokens ist nicht abgelaufen. Branchenstandard-Uhrabweichung beträgt 5 Minuten.
  7. Das Token verfügt über eine gültige kryptografische Signatur mit einem Schlüssel, der in Dokument der OpenID-Schlüssel aufgeführt ist, das in Schritt 3 abgerufen wurde.

Hinweis

Anforderung 5 gilt speziell für den Emulator-Überprüfungspfad.

Wenn das Token nicht alle diese Anforderungen erfüllt, sollte Ihr Bot die Anforderung unter Rückgabe eines HTTP 403 (Unzulässig)-Statuscodes beenden.

Wichtig

Alle diese Anforderungen sind wichtig, besonders die Anforderungen 4 und 7. Wenn nicht ALLE diese Verifizierungsanforderungen implementiert werden, ist der Bot offen für Angriffe, die dazu führen könnten, dass der Bot sein JWT-Token preisgibt.

Emulator an Bot: Beispiel für JWT-Komponenten

header:
{
  typ: "JWT",
  alg: "RS256",
  x5t: "<SIGNING KEY ID>",
  kid: "<SIGNING KEY ID>"
},
payload:
{
  aud: "<YOUR MICROSOFT APP ID>",
  iss: "https://sts.windows.net/d6d49420-f39b-4df7-a1dc-d59a935871db/",
  nbf: 1481049243,
  exp: 1481053143,
  ... other fields follow
}

Hinweis

Die tatsächlichen Felder können in der Praxis variieren. Erstellen und überprüfen Sie alle JWT-Token wie oben angegeben.

Änderungen des Sicherheitsprotokolls

Bot zu Connector-Authentifizierung

OAuth-Anmelde-URL

Protokollversion Gültiger Wert
v3.1 und v3.2 https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token

OAuth-Bereich

Protokollversion Gültiger Wert
v3.1 und v3.2 https://api.botframework.com/.default

Connector zu Bot Authentifizierung

OpenID-Metadatendokument

Protokollversion Gültiger Wert
v3.1 und v3.2 https://login.botframework.com/v1/.well-known/openidconfiguration

JWT-Aussteller

Protokollversion Gültiger Wert
v3.1 und v3.2 https://api.botframework.com

Emulator zu Bot Authentifizierung

OAuth-Anmelde-URL

Protokollversion Gültiger Wert
v3.1 und v3.2 https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token

OAuth-Bereich

Protokollversion Gültiger Wert
v3.1 und v3.2 Microsoft App-ID Ihres Bots und /.default

JWT-Zielgruppe

Protokollversion Gültiger Wert
v3.1 und v3.2 Microsoft App-ID Ihres Bots

JWT-Aussteller

Protokollversion Gültiger Wert
v3.1 1.0 https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/
v3.1 2.0 https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0
v3.2 1.0 https://sts.windows.net/f8cdef31-a31e-4b4a-93e4-5f571e91255a/
v3.2 2.0 https://login.microsoftonline.com/f8cdef31-a31e-4b4a-93e4-5f571e91255a/v2.0

Siehe auch die hervorgehobenen Werte für nichtstaatliche Fälle.

OpenID-Metadatendokument

Protokollversion Gültiger Wert
v3.1 und v3.2 https://login.microsoftonline.com/botframework.com/v2.0/.well-known/openid-configuration

Zusätzliche Ressourcen