Uwierzytelnianie za pomocą interfejsu API Połączenie or bota

Artykuł
10/27/2023

Bot komunikuje się z usługą Bot Połączenie or przy użyciu protokołu HTTP za pośrednictwem zabezpieczonego kanału (SSL/TLS). Gdy bot wysyła żądanie do usługi Połączenie or, musi zawierać informacje, których usługa Połączenie or może użyć do zweryfikowania tożsamości. Podobnie gdy usługa Połączenie or wysyła żądanie do bota, musi zawierać informacje, których bot może użyć do zweryfikowania tożsamości. W tym artykule opisano technologie uwierzytelniania i wymagania dotyczące uwierzytelniania na poziomie usługi, które odbywa się między botem a usługą Bot Połączenie or. Jeśli piszesz własny kod uwierzytelniania, musisz zaimplementować procedury zabezpieczeń opisane w tym artykule, aby umożliwić botowi wymianę komunikatów za pomocą usługi Bot Połączenie or.

Ważne

Jeśli piszesz własny kod uwierzytelniania, ważne jest, aby poprawnie zaimplementować wszystkie procedury zabezpieczeń. Implementując wszystkie kroki opisane w tym artykule, można ograniczyć ryzyko, że osoba atakująca będzie mogła odczytywać wiadomości wysyłane do bota, wysyłać wiadomości, które personifikują bota i kradną klucze tajne.

Jeśli używasz zestawu Bot Framework SDK, nie musisz implementować procedur zabezpieczeń opisanych w tym artykule, ponieważ zestaw SDK automatycznie go wykonuje. Wystarczy skonfigurować projekt przy użyciu identyfikatora aplikacji i hasła uzyskanego dla bota podczas rejestracji , a zestaw SDK obsłuży resztę.

Technologie uwierzytelniania

Cztery technologie uwierzytelniania służą do ustanawiania zaufania między botem a Połączenie or bota:

Technologia	opis
PROTOKÓŁ SSL/TLS	Protokół SSL/TLS jest używany dla wszystkich połączeń typu service-to-service. `X.509v3` Certyfikaty służą do ustanawiania tożsamości wszystkich usług HTTPS. Klienci powinni zawsze sprawdzać certyfikaty usług, aby upewnić się, że są zaufane i prawidłowe. (Certyfikaty klienta NIE są używane w ramach tego schematu).
OAuth 2.0	Protokół OAuth 2.0 używa usługi logowania konta entra firmy Microsoft do generowania bezpiecznego tokenu, którego bot może użyć do wysyłania komunikatów. Ten token jest tokenem typu service-to-service; logowanie użytkownika nie jest wymagane.
Token internetowy JSON (JWT)	Tokeny internetowe JSON są używane do kodowania tokenów wysyłanych do i z bota. Klienci powinni w pełni zweryfikować wszystkie otrzymane tokeny JWT zgodnie z wymaganiami opisanymi w tym artykule.
Metadane OpenID	Usługa Bot Połączenie or publikuje listę prawidłowych tokenów używanych do podpisywania własnych tokenów JWT do metadanych OpenID w dobrze znanym, statycznym punkcie końcowym.

W tym artykule opisano sposób używania tych technologii za pośrednictwem standardowego protokołu HTTPS i formatu JSON. Nie są wymagane żadne specjalne zestawy SDK, chociaż może się okazać, że pomocnicy dla identyfikatora OpenID i innych są przydatne.

Uwierzytelnianie żądań od bota do usługi bota Połączenie or

Aby komunikować się z usługą Bot Połączenie or, należy określić token dostępu w Authorization nagłówku każdego żądania interfejsu API przy użyciu następującego formatu:

Authorization: Bearer ACCESS_TOKEN

Aby uzyskać i użyć tokenu JWT dla bota:

Bot wysyła żądanie HTTP GET do usługi logowania MSA.
Odpowiedź z usługi zawiera token JWT do użycia.
Bot dołącza ten token JWT w nagłówku autoryzacji w żądaniach do usługi Bot Połączenie or.

Ważne

Jeśli jeszcze tego nie zrobiono, musisz zarejestrować bota w narzędziu Bot Framework, aby uzyskać jego identyfikator AppID i hasło. Aby zażądać tokenu dostępu, potrzebny jest identyfikator aplikacji i hasło bota.

Tożsamość bota może być zarządzana na platformie Azure na kilka różnych sposobów.

Jako tożsamość zarządzana przypisana przez użytkownika, aby nie trzeba było samodzielnie zarządzać poświadczeniami bota.
Jako aplikacja z jedną dzierżawą.
Jako aplikacja wielodostępna.

Zażądaj tokenu dostępu na podstawie typu aplikacji bota.

Aby zażądać tokenu dostępu z usługi logowania, wydaj następujące żądanie, zastępując ciąg MICROSOFT-APP-ID i MICROSOFT-APP-PASSWORD identyfikatorem AppID bota i hasłem uzyskanym podczas rejestrowania bota w usłudze Bot Service.

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

Aby zażądać tokenu dostępu z usługi logowania, wydaj następujące żądanie, zastępując ciąg MICROSOFT-APP-ID, MICROSOFT-APP-PASSWORD i MICROSOFT-TENANT-ID identyfikatorem AppID bota, hasłem i identyfikatorem dzierżawy uzyskanym podczas rejestrowania bota w usłudze Bot Service.

POST https://login.microsoftonline.com/MICROSOFT-TENANT-ID/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

Usługa App Service i usługa Azure Functions udostępniają wewnętrznie dostępny punkt końcowy REST na potrzeby pobierania tokenów. Aby zażądać tokenu dostępu z punktu końcowego MSI/token , utwórz żądanie GET do punktu końcowego. Użyj parametrów resource zapytania i client_id . Ustaw resource wartość https://api.botframework.com i client_id na identyfikator aplikacji tożsamości zarządzanej bota. Żądanie nie wymaga innych parametrów zapytania.

Aby uzyskać więcej informacji na temat punktu końcowego tokenu, zobacz Połączenie do usług platformy Azure w kodzie aplikacji.
Aby uzyskać więcej informacji na temat identyfikatorów aplikacji bota, zobacz Tworzenie zasobu usługi Azure Bot.

Jeśli aplikacja jest autoryzowana przez usługę logowania, treść odpowiedzi JSON określi token dostępu, jego typ i wygaśnięcie (w sekundach).

Podczas dodawania tokenu do Authorization nagłówka żądania należy użyć dokładnej wartości określonej w tej odpowiedzi — nie należy unikać ani kodować wartości tokenu. Token dostępu jest ważny do momentu jego wygaśnięcia. Aby zapobiec wygaśnięciu tokenu wpływającemu na wydajność bota, możesz wybrać opcję buforowania i proaktywnego odświeżania tokenu.

W tym przykładzie pokazano odpowiedź z usługi logowania konta Microsoft Entra ID:

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

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

Krok 3. Określanie tokenu JWT w nagłówku autoryzacji żądań

Po wysłaniu żądania interfejsu API do usługi Bot Połączenie or określ token dostępu w Authorization nagłówku żądania przy użyciu następującego formatu:

Authorization: Bearer ACCESS_TOKEN

Wszystkie żądania wysyłane do usługi Bot Połączenie or muszą zawierać token dostępu w nagłówkuAuthorization. Jeśli token jest poprawnie sformułowany, nie wygasł i został wygenerowany przez usługę logowania konta Microsoft Entra ID, usługa Bot Połączenie or autoryzuje żądanie. Wykonywane są dodatkowe kontrole, aby upewnić się, że token należy do bota, który wysłał żądanie.

W poniższym przykładzie pokazano, jak określić token dostępu w Authorization nagłówku żądania.

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

(JSON-serialized Activity message goes here)

Ważne

Określ tylko token JWT w nagłówku Authorization żądań wysyłanych do usługi Bot Połączenie or. NIE wysyłaj tokenu za pośrednictwem niezabezpieczonych kanałów i nie dołączaj go do żądań HTTP wysyłanych do innych usług. Token JWT uzyskany z usługi logowania konta Entra firmy Microsoft jest jak hasło i powinien być dobrze obsługiwany. Każdy, kto posiada token, może używać go do wykonywania operacji w imieniu bota.

Bot do Połączenie or: przykładowe składniki JWT

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
}

Uwaga

Rzeczywiste pola mogą się różnić w praktyce. Utwórz i zweryfikuj wszystkie tokeny JWT, jak określono powyżej.

Uwierzytelnianie żądań z usługi Bot Połączenie or do bota

Gdy usługa Bot Połączenie or wysyła żądanie do bota, określa podpisany token JWT w Authorization nagłówku żądania. Bot może uwierzytelniać wywołania z usługi Bot Połączenie or, sprawdzając autentyczność podpisanego tokenu JWT.

Aby uwierzytelnić wywołania z usługi Bot Połączenie or:

Bot pobiera token JWT z nagłówka autoryzacji w żądaniach wysyłanych z usługi Bot Połączenie or.
Bot pobiera dokument metadanych OpenID dla usługi Bot Połączenie or.
Bot pobiera listę prawidłowych kluczy podpisywania z dokumentu.
Bot weryfikuje autentyczność tokenu JWT.

Krok 2. Pobieranie dokumentu metadanych OpenID

Dokument metadanych OpenID określa lokalizację drugiego dokumentu, który zawiera listę prawidłowych kluczy podpisywania usługi Bot Połączenie or. Aby uzyskać dokument metadanych OpenID, wydaj to żądanie za pośrednictwem protokołu HTTPS:

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

Napiwek

Jest to statyczny adres URL, który można trwale zakodować w aplikacji.

W poniższym przykładzie przedstawiono dokument metadanych OpenID zwracany w odpowiedzi na GET żądanie. Właściwość jwks_uri określa lokalizację dokumentu, który zawiera prawidłowe klucze podpisywania usługi Bot Połączenie or.

{
    "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"
    ]
}

Krok 3. Pobieranie listy prawidłowych kluczy podpisywania

Aby uzyskać listę prawidłowych kluczy podpisywania, należy wysłać GET żądanie za pośrednictwem protokołu HTTPS do adresu URL określonego jwks_uri przez właściwość w dokumencie metadanych OpenID. Na przykład:

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

Treść odpowiedzi określa dokument w formacie JWK, ale także zawiera dodatkową właściwość dla każdego klucza: endorsements.

Napiwek

Lista kluczy jest stabilna i może być buforowana, ale nowe klucze mogą być dodawane w dowolnym momencie. Aby upewnić się, że bot ma aktualną kopię dokumentu przed ich zastosowaniem, wszystkie wystąpienia botów powinny odświeżać lokalną pamięć podręczną dokumentu co najmniej raz na 24 godziny.

Właściwość endorsements w każdym kluczu zawiera co najmniej jeden ciąg poręczenia, którego można użyć do sprawdzenia, czy identyfikator kanału określony we channelId właściwości w obiekcie Activity żądania przychodzącego jest autentyczny. Lista identyfikatorów kanałów, które wymagają poręczenia, jest konfigurowalna w ramach każdego bota. Domyślnie będzie to lista wszystkich opublikowanych identyfikatorów kanałów, chociaż deweloperzy botów mogą przesłonić wybrane wartości identyfikatorów kanału w dowolny sposób.

Krok 4. Weryfikowanie tokenu JWT

Aby sprawdzić autentyczność tokenu wysłanego przez usługę Bot Połączenie or, należy wyodrębnić token z Authorization nagłówka żądania, przeanalizować token, zweryfikować jego zawartość i zweryfikować jego podpis.

Biblioteki analizy JWT są dostępne dla wielu platform i najbardziej implementują bezpieczne i niezawodne analizowanie tokenów JWT, chociaż zazwyczaj należy skonfigurować te biblioteki, aby wymagać, aby niektóre cechy tokenu (jego wystawca, odbiorcy itd.) zawierały prawidłowe wartości. Podczas analizowania tokenu należy skonfigurować bibliotekę analizowania lub napisać własną walidację, aby upewnić się, że token spełnia następujące wymagania:

Token został wysłany w nagłówku HTTP Authorization ze schematem "Bearer".
Token jest prawidłowym kodem JSON zgodnym ze standardem JWT.
Token zawiera oświadczenie "wystawcy https://api.botframework.com" o wartości .
Token zawiera oświadczenie "odbiorców" z wartością równą identyfikatorowi aplikacji microsoft bota.
Token mieści się w okresie ważności. Standardowe w branży niesymetryczność zegara wynosi 5 minut.
Token ma prawidłowy podpis kryptograficzny z kluczem wymienionym w dokumencie Kluczy OpenID pobranym w kroku 3 przy użyciu algorytmu podpisywania określonego we id_token_signing_alg_values_supported właściwości dokumentu Metadane identyfikatora otwierania pobranego w kroku 2.
Token zawiera oświadczenie "serviceUrl" z wartością zgodną serviceUrl z właściwością w katalogu głównym obiektu Activity żądania przychodzącego.

Jeśli wymagane jest poparcie dla identyfikatora kanału:

Należy wymagać, aby każdy Activity obiekt wysłany do bota z tym identyfikatorem kanału towarzyszył token JWT podpisany przy użyciu poręczenia dla tego kanału.
Jeśli poparcie nie jest obecne, bot powinien odrzucić żądanie, zwracając kod stanu HTTP 403 (Zabronione).

Ważne

Wszystkie te wymagania są ważne, szczególnie wymagania 4 i 6. Nie zaimplementowanie wszystkich tych wymagań weryfikacyjnych spowoduje pozostawienie bota otwartego na ataki, co może spowodować ujawnienie tokenu JWT przez bota.

Implementatory nie powinny uwidaczniać sposobu wyłączania walidacji tokenu JWT wysyłanego do bota.

Połączenie or do bota: przykładowe składniki JWT

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
}

Uwaga

Rzeczywiste pola mogą się różnić w praktyce. Utwórz i zweryfikuj wszystkie tokeny JWT, jak określono powyżej.

Uwierzytelnianie żądań z bota Bot Framework Emulator do bota

Bot Framework Emulator to narzędzie klasyczne, którego można użyć do testowania funkcjonalności bota. Mimo że emulator bot framework używa tych samych technologii uwierzytelniania, jak opisano powyżej, nie może personifikować rzeczywistej usługi bota Połączenie or. Zamiast tego używa ono identyfikatora aplikacji firmy Microsoft i hasła aplikacji firmy Microsoft określonego podczas łączenia emulatora z botem w celu utworzenia tokenów identycznych z utworzonymi przez bota. Gdy emulator wysyła żądanie do bota, określa token JWT w Authorization nagłówku żądania — w istocie przy użyciu własnych poświadczeń bota do uwierzytelniania żądania.

Jeśli wdrażasz bibliotekę uwierzytelniania i chcesz akceptować żądania z emulatora platformy Bot Framework, musisz dodać tę dodatkową ścieżkę weryfikacji. Ścieżka jest strukturalnie podobna do ścieżki Połączenie or —> ścieżka weryfikacji bota, ale używa dokumentu OpenID msA zamiast dokumentu OpenID bota Połączenie or.

Aby uwierzytelnić wywołania z poziomu emulatora platformy Bot Framework:

Bot pobiera token JWT z nagłówka autoryzacji w żądaniach wysyłanych z bot Framework Emulator.
Bot pobiera dokument metadanych OpenID dla usługi Bot Połączenie or.
Bot pobiera listę prawidłowych kluczy podpisywania z dokumentu.
Bot weryfikuje autentyczność tokenu JWT.

Krok 2. Pobieranie dokumentu metadanych identyfikatora OpenID msA

Dokument metadanych OpenID określa lokalizację drugiego dokumentu, który zawiera listę prawidłowych kluczy podpisywania. Aby uzyskać dokument metadanych openID msA, wydaj to żądanie za pośrednictwem protokołu HTTPS:

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

W poniższym przykładzie przedstawiono dokument metadanych OpenID zwracany w odpowiedzi na GET żądanie. Właściwość jwks_uri określa lokalizację dokumentu zawierającego prawidłowe klucze podpisywania.

{
    "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",
    ...
}

Krok 3. Pobieranie listy prawidłowych kluczy podpisywania

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

Treść odpowiedzi określa dokument w formacie JWK.

Krok 4. Weryfikowanie tokenu JWT

Aby sprawdzić autentyczność tokenu, który został wysłany przez emulator, należy wyodrębnić token z Authorization nagłówka żądania, przeanalizować token, zweryfikować jego zawartość i zweryfikować jego podpis.

Token został wysłany w nagłówku HTTP Authorization ze schematem "Bearer".
Token jest prawidłowym kodem JSON zgodnym ze standardem JWT.
Token zawiera oświadczenie "wystawcy" z jedną z wyróżnionych wartości dla przypadków pozarządowych. Sprawdzanie obu wartości wystawcy zapewni sprawdzenie wartości wystawcy zarówno dla protokołu zabezpieczeń w wersji 3.1, jak i 3.2.
Token zawiera oświadczenie "odbiorców" z wartością równą identyfikatorowi aplikacji microsoft bota.
Emulator, w zależności od wersji, wysyła identyfikator AppId za pośrednictwem oświadczenia appid (wersja 1) lub oświadczenia autoryzowanej jednostki (wersja 2).
Token mieści się w okresie ważności. Standardowe w branży niesymetryczność zegara wynosi 5 minut.
Token ma prawidłowy podpis kryptograficzny z kluczem wymienionym w dokumencie Kluczy OpenID, który został pobrany w kroku 3.

Uwaga

Wymaganie 5 jest specyficzne dla ścieżki weryfikacji emulatora.

Jeśli token nie spełnia wszystkich tych wymagań, bot powinien zakończyć żądanie, zwracając kod stanu HTTP 403 (Zabronione).

Ważne

Wszystkie te wymagania są ważne, szczególnie wymagania 4 i 7. Nie zaimplementowanie wszystkich tych wymagań weryfikacyjnych spowoduje pozostawienie bota otwartego na ataki, co może spowodować ujawnienie tokenu JWT przez bota.

Emulator do bota: przykładowe składniki JWT

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
}

Uwaga

Rzeczywiste pola mogą się różnić w praktyce. Utwórz i zweryfikuj wszystkie tokeny JWT, jak określono powyżej.

Zmiany protokołu zabezpieczeń

Bot do uwierzytelniania Połączenie or

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	`https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token`

Zakres OAuth

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	`https://api.botframework.com/.default`

Połączenie or do uwierzytelniania bota

Dokument metadanych OpenID

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	`https://login.botframework.com/v1/.well-known/openidconfiguration`

Wystawca JWT

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	`https://api.botframework.com`

Uwierzytelnianie emulatora do bota

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	`https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token`

Zakres OAuth

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	Identyfikator aplikacji microsoft bota i `/.default`

Odbiorcy JWT

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	Identyfikator aplikacji microsoft bota

Wystawca JWT

Wersja protokołu	Prawidłowa wartość
wersja 3.1 1.0	`https://sts.windows.net/d6d49420-f39b-4df7-a1dc-d59a935871db/`
Wersja 3.1 2.0	`https://login.microsoftonline.com/d6d49420-f39b-4df7-a1dc-d59a935871db/v2.0`
Wersja 3.2 1.0	`https://sts.windows.net/f8cdef31-a31e-4b4a-93e4-5f571e91255a/`
Wersja 3.2 2.0	`https://login.microsoftonline.com/f8cdef31-a31e-4b4a-93e4-5f571e91255a/v2.0`

Zobacz również wyróżnione wartości dla przypadków pozarządowych.

Dokument metadanych OpenID

Wersja protokołu	Prawidłowa wartość
Wersja 3.1 i wersja 3.2	`https://login.microsoftonline.com/botframework.com/v2.0/.well-known/openid-configuration`

Udostępnij za pośrednictwem

Uwierzytelnianie za pomocą interfejsu API Połączenie or bota

Technologie uwierzytelniania

Uwierzytelnianie żądań od bota do usługi bota Połączenie or

Krok 3. Określanie tokenu JWT w nagłówku autoryzacji żądań

Bot do Połączenie or: przykładowe składniki JWT

Uwierzytelnianie żądań z usługi Bot Połączenie or do bota

Krok 2. Pobieranie dokumentu metadanych OpenID

Krok 3. Pobieranie listy prawidłowych kluczy podpisywania

Krok 4. Weryfikowanie tokenu JWT

Połączenie or do bota: przykładowe składniki JWT

Uwierzytelnianie żądań z bota Bot Framework Emulator do bota

Krok 2. Pobieranie dokumentu metadanych identyfikatora OpenID msA

Krok 3. Pobieranie listy prawidłowych kluczy podpisywania

Krok 4. Weryfikowanie tokenu JWT

Emulator do bota: przykładowe składniki JWT

Zmiany protokołu zabezpieczeń

Bot do uwierzytelniania Połączenie or

Zakres OAuth

Połączenie or do uwierzytelniania bota

Dokument metadanych OpenID

Wystawca JWT

Uwierzytelnianie emulatora do bota

Zakres OAuth

Odbiorcy JWT

Wystawca JWT

Dokument metadanych OpenID

Dodatkowe zasoby

Dodatkowe zasoby

Udostępnij za pośrednictwem

Uwierzytelnianie za pomocą interfejsu API Połączenie or bota

Technologie uwierzytelniania

Uwierzytelnianie żądań od bota do usługi bota Połączenie or

Krok 1. Żądanie tokenu dostępu z usługi logowania konta Entra ID firmy Microsoft

Krok 2. Uzyskiwanie tokenu JWT z odpowiedzi usługi logowania konta Microsoft Entra ID

Krok 3. Określanie tokenu JWT w nagłówku autoryzacji żądań

Bot do Połączenie or: przykładowe składniki JWT

Uwierzytelnianie żądań z usługi Bot Połączenie or do bota

Krok 2. Pobieranie dokumentu metadanych OpenID

Krok 3. Pobieranie listy prawidłowych kluczy podpisywania

Krok 4. Weryfikowanie tokenu JWT

Połączenie or do bota: przykładowe składniki JWT

Uwierzytelnianie żądań z bota Bot Framework Emulator do bota

Krok 2. Pobieranie dokumentu metadanych identyfikatora OpenID msA

Krok 3. Pobieranie listy prawidłowych kluczy podpisywania

Krok 4. Weryfikowanie tokenu JWT

Emulator do bota: przykładowe składniki JWT

Zmiany protokołu zabezpieczeń

Bot do uwierzytelniania Połączenie or

Adres URL logowania OAuth

Zakres OAuth

Połączenie or do uwierzytelniania bota

Dokument metadanych OpenID

Wystawca JWT

Uwierzytelnianie emulatora do bota

Adres URL logowania OAuth

Zakres OAuth

Odbiorcy JWT

Wystawca JWT

Dokument metadanych OpenID

Dodatkowe zasoby

Dodatkowe zasoby