Udostępnij za pośrednictwem


Wywołania typu usługa-usługa korzystające z delegowanej tożsamości użytkownika w przepływie On-Behalf-Of

Ostrzeżenie

Ta zawartość jest przeznaczona dla starszego punktu końcowego Azure AD w wersji 1.0. Użyj Platforma tożsamości Microsoft dla nowych projektów.

Przepływ OAuth 2.0 On-Behalf-Of (OBO) umożliwia aplikacji, która wywołuje usługę lub internetowy interfejs API w celu przekazania uwierzytelniania użytkownika do innej usługi lub internetowego interfejsu API. Przepływ OBO propaguje tożsamość delegowanego użytkownika i uprawnienia za pośrednictwem łańcucha żądań. Aby usługa warstwy środkowej wysyłała uwierzytelnione żądania do usługi podrzędnej, musi zabezpieczyć token dostępu z usługi Azure Active Directory (Azure AD) w imieniu użytkownika.

Ważne

Od maja 2018 r. nie można użyć elementu id_token dla przepływu On-Behalf-Of. Aplikacje jednostronicowe (SPA) muszą przekazać token dostępu do poufnego klienta warstwy środkowej w celu wykonywania przepływów OBO. Aby uzyskać więcej informacji na temat klientów, którzy mogą wykonywać wywołania on-Behalf-Of, zobacz ograniczenia.

Diagram przepływu w imieniu

Przepływ OBO rozpoczyna się po uwierzytelnieniu użytkownika w aplikacji korzystającej z przepływu udzielania kodu autoryzacji OAuth 2.0. W tym momencie aplikacja wysyła token dostępu (token A) do internetowego interfejsu API (API A) warstwy środkowej zawierającego oświadczenia użytkownika i zgodę na dostęp do interfejsu API A. Następnie interfejs API A wysyła uwierzytelnione żądanie do podrzędnego internetowego interfejsu API (API B).

Te kroki stanowią przepływ On-Behalf-Of: Przedstawia kroki przepływu OAuth2.0 w imieniu przepływu

  1. Aplikacja kliencka wysyła żądanie do interfejsu API A z tokenem A.
  2. Interfejs API A uwierzytelnia się w punkcie końcowym wystawiania tokenu Azure AD i żąda tokenu dostępu do interfejsu API B.
  3. Punkt końcowy wystawiania tokenu Azure AD weryfikuje poświadczenia interfejsu API A z tokenem A i wystawia token dostępu dla interfejsu API B (token B).
  4. Żądanie interfejsu API B zawiera token B w nagłówku autoryzacji.
  5. Interfejs API B zwraca dane z zabezpieczonego zasobu.

Uwaga

Oświadczenie odbiorców w tokenie dostępu używanym do żądania tokenu dla usługi podrzędnej musi być identyfikatorem usługi wysyłającej żądanie OBO. Token musi być również podpisany przy użyciu klucza globalnego podpisywania usługi Azure Active Directory (który jest domyślny dla aplikacji zarejestrowanych za pośrednictwem Rejestracje aplikacji w portalu).

Rejestrowanie aplikacji i usługi w Azure AD

Zarejestruj zarówno usługę warstwy środkowej, jak i aplikację kliencą w Azure AD.

Rejestrowanie usługi warstwy środkowej

  1. Zaloguj się w witrynie Azure Portal.
  2. Na górnym pasku wybierz swoje konto i poszukaj go na liście Katalog , aby wybrać dzierżawę usługi Active Directory dla aplikacji.
  3. Wybierz pozycję Więcej usług w okienku po lewej stronie i wybierz pozycję Azure Active Directory.
  4. Wybierz pozycję Rejestracje aplikacji, a następnie pozycję Nowa rejestracja.
  5. Wprowadź przyjazną nazwę aplikacji i wybierz typ aplikacji.
  6. W obszarze Obsługiwane typy kont wybierz pozycję Konta w dowolnym katalogu organizacyjnym i konta osobiste Microsoft.
  7. Ustaw identyfikator URI przekierowania na podstawowy adres URL.
  8. Wybierz pozycję Zarejestruj, aby utworzyć aplikację.
  9. W Azure Portal wybierz aplikację i wybierz pozycję Certyfikaty & wpisy tajne.
  10. Wybierz pozycję Nowy klucz tajny klienta i dodaj wpis tajny z czasem trwania jednego lub dwóch lat.
  11. Po zapisaniu tej strony Azure Portal wyświetla wartość wpisu tajnego. Skopiuj i zapisz wartość wpisu tajnego w bezpiecznej lokalizacji.
  12. Utwórz zakres w aplikacji na stronie Uwidacznianie interfejsu API dla aplikacji i kliknięcie pozycji "Dodaj zakres". Portal może wymagać również utworzenia identyfikatora URI identyfikatora aplikacji.

Ważne

Aby skonfigurować ustawienia aplikacji we implementacji, potrzebny jest wpis tajny. Ta wartość wpisu tajnego nie jest ponownie wyświetlana i nie jest ona pobierana w żaden inny sposób. Zarejestruj go tak szybko, jak jest widoczny w Azure Portal.

Rejestrowanie aplikacji klienckiej

  1. Zaloguj się w witrynie Azure Portal.
  2. Na górnym pasku wybierz swoje konto i poszukaj go na liście Katalog , aby wybrać dzierżawę usługi Active Directory dla aplikacji.
  3. Wybierz pozycję Więcej usług w okienku po lewej stronie i wybierz pozycję Azure Active Directory.
  4. Wybierz pozycję Rejestracje aplikacji, a następnie pozycję Nowa rejestracja.
  5. Wprowadź przyjazną nazwę aplikacji i wybierz typ aplikacji.
  6. W obszarze Obsługiwane typy kont wybierz pozycję Konta w dowolnym katalogu organizacyjnym i konta osobiste Microsoft.
  7. Ustaw identyfikator URI przekierowania na podstawowy adres URL.
  8. Wybierz pozycję Zarejestruj, aby utworzyć aplikację.
  9. Konfigurowanie uprawnień dla aplikacji. W obszarze Uprawnienia interfejsu API wybierz pozycję Dodaj uprawnienie , a następnie pozycję Moje interfejsy API.
  10. Wpisz nazwę usługi warstwy środkowej w polu tekstowym.
  11. Wybierz pozycję Wybierz uprawnienia , a następnie wybierz zakres utworzony w ostatnim kroku rejestrowania warstwy środkowej.

Konfigurowanie znanych aplikacji klienckich

W tym scenariuszu usługa warstwy środkowej musi uzyskać zgodę użytkownika na dostęp do podrzędnego interfejsu API bez interakcji użytkownika. Opcja udzielenia dostępu do podrzędnego interfejsu API musi zostać przedstawiona z góry w ramach kroku zgody podczas uwierzytelniania.

Wykonaj poniższe kroki, aby jawnie powiązać rejestrację aplikacji klienckiej w Azure AD z rejestracją usługi warstwy środkowej. Ta operacja scala zgodę wymaganą zarówno przez klienta, jak i warstwę środkową w jednym oknie dialogowym.

  1. Przejdź do rejestracji usługi warstwy środkowej i wybierz pozycję Manifest , aby otworzyć edytor manifestu.
  2. Znajdź właściwość tablicy knownClientApplications i dodaj identyfikator klienta aplikacji klienckiej jako element.
  3. Zapisz manifest, wybierając pozycję Zapisz.

Żądanie tokenu dostępu do usługi

Aby zażądać tokenu dostępu, utwórz adres HTTP POST do punktu końcowego Azure AD specyficznego dla dzierżawy z następującymi parametrami:

https://login.microsoftonline.com/<tenant>/oauth2/token

Aplikacja kliencka jest zabezpieczona przez wspólny klucz tajny lub certyfikat.

Pierwszy przypadek: żądanie tokenu dostępu z udostępnionym wpisem tajnym

W przypadku korzystania z udostępnionego wpisu tajnego żądanie tokenu dostępu typu service-to-service zawiera następujące parametry:

Parametr Typ Opis
grant_type wymagane Typ żądania tokenu. Żądanie OBO używa tokenu internetowego JSON (JWT), więc wartość musi być urn:ietf:params:oauth:grant-type:jwt-bearer.
Potwierdzenia wymagane Wartość tokenu dostępu używanego w żądaniu.
client_id wymagane Identyfikator aplikacji przypisany do usługi wywołującej podczas rejestracji z Azure AD. Aby znaleźć identyfikator aplikacji w Azure Portal, wybierz pozycję Active Directory, wybierz katalog, a następnie wybierz nazwę aplikacji.
client_secret wymagane Klucz zarejestrowany dla usługi wywołującej w Azure AD. Ta wartość powinna zostać zanotowana w momencie rejestracji.
zasób wymagane Identyfikator URI aplikacji odbierającego usługi (zabezpieczony zasób). Aby znaleźć identyfikator URI identyfikatora aplikacji w Azure Portal, wybierz pozycję Active Directory i wybierz katalog. Wybierz nazwę aplikacji, wybierz pozycję Wszystkie ustawienia, a następnie wybierz pozycję Właściwości.
requested_token_use wymagane Określa sposób przetwarzania żądania. W przepływie On-Behalf-Of wartość musi być on_behalf_of.
scope wymagane Rozdzielona spacją lista zakresów dla żądania tokenu. W przypadku openID Connect należy określić identyfikator openid zakresu.

Przykład

Następujący kod HTTP POST żąda tokenu dostępu dla internetowego interfejsu https://graph.microsoft.com API. Element client_id identyfikuje usługę, która żąda tokenu dostępu.

// line breaks for legibility only

POST /oauth2/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_secret=0Y1W%2BY3yYb3d9N8vSjvm8WrGzVZaAaHbHHcGbcgG%2BoI%3D
&resource=https%3A%2F%2Fgraph.microsoft.com
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.ewogICJhdWQiOiAiaHR0cHM6Ly9ncmFwaC5taWNyb3NvZnQuY29tIiwKICAiaXNzIjogImh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzI2MDM5Y2NlLTQ4OWQtNDAwMi04MjkzLTViMGM1MTM0ZWFjYi8iLAogICJpYXQiOiAxNDkzNDIzMTY4LAogICJuYmYiOiAxNDkzNDIzMTY4LAogICJleHAiOiAxNDkzNDY2OTUxLAogICJhY3IiOiAiMSIsCiAgImFpbyI6ICJBU1FBMi84REFBQUE1NnZGVmp0WlNjNWdBVWwrY1Z0VFpyM0VvV2NvZEoveWV1S2ZqcTZRdC9NPSIsCiAgImFtciI6IFsKICAgICJwd2QiCiAgXSwKICAiYXBwaWQiOiAiNjI1MzkxYWYtYzY3NS00M2U1LThlNDQtZWRkM2UzMGNlYjE1IiwKICAiYXBwaWRhY3IiOiAiMSIsCiAgImVfZXhwIjogMzAyNjgzLAogICJmYW1pbHlfbmFtZSI6ICJUZXN0IiwKICAiZ2l2ZW5fbmFtZSI6ICJOYXZ5YSIsCiAgImlwYWRkciI6ICIxNjcuMjIwLjEuMTc3IiwKICAibmFtZSI6ICJOYXZ5YSBUZXN0IiwKICAib2lkIjogIjFjZDRiY2FjLWI4MDgtNDIzYS05ZTJmLTgyN2ZiYjFiYjczOSIsCiAgInBsYXRmIjogIjMiLAogICJwdWlkIjogIjEwMDMzRkZGQTEyRUQ3RkUiLAogICJzY3AiOiAiVXNlci5SZWFkIiwKICAic3ViIjogIjNKTUlaSWJlYTc1R2hfWHdDN2ZzX0JDc3kxa1l1ekZKLTUyVm1Zd0JuM3ciLAogICJ0aWQiOiAiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwKICAidW5pcXVlX25hbWUiOiAibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLAogICJ1cG4iOiAibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLAogICJ1dGkiOiAieEN3ZnpoYS1QMFdKUU9MeENHZ0tBQSIsCiAgInZlciI6ICIxLjAiCn0.cqmUVjfVbqWsxJLUI1Z4FRx1mNQAHP-L0F4EMN09r8FY9bIKeO-0q1eTdP11Nkj_k4BmtaZsTcK_mUygdMqEp9AfyVyA1HYvokcgGCW_Z6DMlVGqlIU4ssEkL9abgl1REHElPhpwBFFBBenOk9iHddD1GddTn6vJbKC3qAaNM5VarjSPu50bVvCrqKNvFixTb5bbdnSz-Qr6n6ACiEimiI1aNOPR2DeKUyWBPaQcU5EAK0ef5IsVJC1yaYDlAcUYIILMDLCD9ebjsy0t9pj_7lvjzUSrbMdSCCdzCqez_MSNxrk1Nu9AecugkBYp3UVUZOIyythVrj6-sVvLZKUutQ
&requested_token_use=on_behalf_of
&scope=openid

Drugi przypadek: Żądanie tokenu dostępu z certyfikatem

Żądanie tokenu dostępu typu usługa-usługa z certyfikatem zawiera następujące parametry:

Parametr Typ Opis
grant_type wymagane Typ żądania tokenu. Żądanie OBO używa tokenu dostępu JWT, więc wartość musi być urn:ietf:params:oauth:grant-type:jwt-bearer.
Potwierdzenia wymagane Wartość tokenu użytego w żądaniu.
client_id wymagane Identyfikator aplikacji przypisany do usługi wywołującej podczas rejestracji za pomocą Azure AD. Aby znaleźć identyfikator aplikacji w Azure Portal, wybierz pozycję Active Directory, wybierz katalog, a następnie wybierz nazwę aplikacji.
client_assertion_type wymagane Wartość musi być urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion wymagane Token internetowy JSON, który tworzysz i podpisujesz przy użyciu certyfikatu zarejestrowanego jako poświadczenia dla aplikacji. Zobacz poświadczenia certyfikatu , aby dowiedzieć się więcej o formacie asercji i sposobie rejestrowania certyfikatu.
zasób wymagane Identyfikator URI aplikacji usługi odbierania (zabezpieczony zasób). Aby znaleźć identyfikator URI identyfikatora aplikacji w Azure Portal, wybierz pozycję Active Directory i wybierz katalog. Wybierz nazwę aplikacji, wybierz pozycję Wszystkie ustawienia, a następnie wybierz pozycję Właściwości.
requested_token_use wymagane Określa sposób przetwarzania żądania. W przepływie On-Behalf-Of wartość musi być on_behalf_of.
scope wymagane Rozdzielona spacją lista zakresów dla żądania tokenu. W przypadku openID Connect należy określić identyfikator openid zakresu.

Te parametry są prawie takie same jak w przypadku żądania udostępnionego wpisu tajnego, z tą różnicą, że client_secret parameter parametr jest zastępowany przez dwa parametry: client_assertion_type i client_assertion.

Przykład

Następujący kod HTTP POST żąda tokenu dostępu dla internetowego interfejsu https://graph.microsoft.com API z certyfikatem. Element client_id identyfikuje usługę, która żąda tokenu dostępu.

// line breaks for legibility only

POST /oauth2/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&resource=https%3A%2F%2Fgraph.microsoft.com
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiJodHRwczovL2Rkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tLzE5MjNmODYyLWU2ZGMtNDFhMy04MWRhLTgwMmJhZTAwYWY2ZCIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzI2MDM5Y2NlLTQ4OWQtNDAwMi04MjkzLTViMGM1MTM0ZWFjYi8iLCJpYXQiOjE0OTM0MjMxNTIsIm5iZiI6MTQ5MzQyMzE1MiwiZXhwIjoxNDkzNDY2NjUyLCJhY3IiOiIxIiwiYWlvIjoiWTJaZ1lCRFF2aTlVZEc0LzM0L3dpQndqbjhYeVp4YmR1TFhmVE1QeG8yYlN2elgreHBVQSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiJiMzE1MDA3OS03YmViLTQxN2YtYTA2YS0zZmRjNzhjMzI1NDUiLCJhcHBpZGFjciI6IjAiLCJlX2V4cCI6MzAyNDAwLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJEVXpYbkdKMDJIUk0zRW5pbDFxdjZCakxTNUllQy0tQ2ZpbzRxS1MzNEc4IiwidGlkIjoiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwidW5pcXVlX25hbWUiOiJuYXZ5YUBkZG9iYWxpYW5vdXRsb29rLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidmVyIjoiMS4wIn0.R-Ke-XO7lK0r5uLwxB8g5CrcPAwRln5SccJCfEjU6IUqpqcjWcDzeDdNOySiVPDU_ZU5knJmzRCF8fcjFtPsaA4R7vdIEbDuOur15FXSvE8FvVSjP_49OH6hBYqoSUAslN3FMfbO6Z8YfCIY4tSOB2I6ahQ_x4ZWFWglC3w5mK-_4iX81bqi95eV4RUKefUuHhQDXtWhrSgIEC0YiluMvA4TnaJdLq_tWXIc4_Tq_KfpkvI004ONKgU7EAMEr1wZ4aDcJV2yf22gQ1sCSig6EGSTmmzDuEPsYiyd4NhidRZJP4HiiQh-hePBQsgcSgYGvz9wC6n57ufYKh2wm_Ti3Q
&requested_token_use=on_behalf_of
&scope=openid

Odpowiedź tokenu dostępu typu usługa-usługa

Odpowiedź z informacją o powodzeniu to odpowiedź JSON OAuth 2.0 z następującymi parametrami:

Parametr Opis
token_type Wskazuje wartość typu tokenu. Jedynym typem, który obsługuje Azure AD jest Bearer. Aby uzyskać więcej informacji na temat tokenów elementu nośnego, zobacz OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750).
scope Zakres dostępu udzielony w tokenie.
expires_in Czas ważności tokenu dostępu (w sekundach).
expires_on Czas wygaśnięcia tokenu dostępu. Data jest reprezentowana jako liczba sekund od 1970-01-01T0:0:0Z UTC do czasu wygaśnięcia. Ta wartość służy do określania okresu istnienia buforowanych tokenów.
zasób Identyfikator URI aplikacji usługi odbierania (zabezpieczony zasób).
access_token Żądany token dostępu. Usługa wywołująca może używać tego tokenu do uwierzytelniania w usłudze odbierającej.
id_token Żądany token identyfikatora. Usługa wywołująca może użyć tego tokenu do zweryfikowania tożsamości użytkownika i rozpoczęcia sesji z użytkownikiem.
refresh_token Token odświeżania dla żądanego tokenu dostępu. Usługa wywołująca może używać tego tokenu do żądania innego tokenu dostępu po wygaśnięciu bieżącego tokenu dostępu.

Przykład odpowiedzi na powodzenie

Poniższy przykład przedstawia odpowiedź powodzenia na żądanie tokenu dostępu dla internetowego interfejsu https://graph.microsoft.com API.

{
    "token_type":"Bearer",
    "scope":"User.Read",
    "expires_in":"43482",
    "ext_expires_in":"302683",
    "expires_on":"1493466951",
    "not_before":"1493423168",
    "resource":"https://graph.microsoft.com",
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0IiwiaXNzIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiLyIsImlhdCI6MTQ5MzQyMzE2OCwibmJmIjoxNDkzNDIzMTY4LCJleHAiOjE0OTM0NjY5NTEsImFjciI6IjEiLCJhaW8iOiJBU1FBMi84REFBQUE1NnZGVmp0WlNjNWdBVWwrY1Z0VFpyM0VvV2NvZEoveWV1S2ZqcTZRdC9NPSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiI2MjUzOTFhZi1jNjc1LTQzZTUtOGU0NC1lZGQzZTMwY2ViMTUiLCJhcHBpZGFjciI6IjEiLCJlX2V4cCI6MzAyNjgzLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJwdWlkIjoiMTAwMzNGRkZBMTJFRDdGRSIsInNjcCI6IlVzZXIuUmVhZCIsInN1YiI6IjNKTUlaSWJlYTc1R2hfWHdDN2ZzX0JDc3kxa1l1ekZKLTUyVm1Zd0JuM3ciLCJ0aWQiOiIyNjAzOWNjZS00ODlkLTQwMDItODI5My01YjBjNTEzNGVhY2IiLCJ1bmlxdWVfbmFtZSI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidXBuIjoibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJ4Q3dmemhhLVAwV0pRT0x4Q0dnS0FBIiwidmVyIjoiMS4wIn0.cqmUVjfVbqWsxJLUI1Z4FRx1mNQAHP-L0F4EMN09r8FY9bIKeO-0q1eTdP11Nkj_k4BmtaZsTcK_mUygdMqEp9AfyVyA1HYvokcgGCW_Z6DMlVGqlIU4ssEkL9abgl1REHElPhpwBFFBBenOk9iHddD1GddTn6vJbKC3qAaNM5VarjSPu50bVvCrqKNvFixTb5bbdnSz-Qr6n6ACiEimiI1aNOPR2DeKUyWBPaQcU5EAK0ef5IsVJC1yaYDlAcUYIILMDLCD9ebjsy0t9pj_7lvjzUSrbMdSCCdzCqez_MSNxrk1Nu9AecugkBYp3UVUZOIyythVrj6-sVvLZKUutQ",
    "refresh_token":"AQABAAAAAABnfiG-mA6NTae7CdWW7QfdjKGu9-t1scy_TDEmLi4eLQMjJGt_nAoVu6A4oSu1KsRiz8XyQIPKQxSGfbf2FoSK-hm2K8TYzbJuswYusQpJaHUQnSqEvdaCeFuqXHBv84wjFhuanzF9dQZB_Ng5za9xKlUENrNtlq9XuLNVKzxEyeUM7JyxzdY7JiEphWImwgOYf6II316d0Z6-H3oYsFezf4Xsjz-MOBYEov0P64UaB5nJMvDyApV-NWpgklLASfNoSPGb67Bc02aFRZrm4kLk-xTl6eKE6hSo0XU2z2t70stFJDxvNQobnvNHrAmBaHWPAcC3FGwFnBOojpZB2tzG1gLEbmdROVDp8kHEYAwnRK947Py12fJNKExUdN0njmXrKxNZ_fEM33LHW1Tf4kMX_GvNmbWHtBnIyG0w5emb-b54ef5AwV5_tGUeivTCCysgucEc-S7G8Cz0xNJ_BOiM_4bAv9iFmrm9STkltpz0-Tftg8WKmaJiC0xXj6uTf4ZkX79mJJIuuM7XP4ARIcLpkktyg2Iym9jcZqymRkGH2Rm9sxBwC4eeZXM7M5a7TJ-5CqOdfuE3sBPq40RdEWMFLcrAzFvP0VDR8NKHIrPR1AcUruat9DETmTNJukdlJN3O41nWdZOVoJM-uKN3uz2wQ2Ld1z0Mb9_6YfMox9KTJNzRzcL52r4V_y3kB6ekaOZ9wQ3HxGBQ4zFt-2U0mSszIAA",
    "id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiI2MjUzOTFhZi1jNjc1LTQzZTUtOGU0NC1lZGQzZTMwY2ViMTUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC8yNjAzOWNjZS00ODlkLTQwMDItODI5My01YjBjNTEzNGVhY2IvIiwiaWF0IjoxNDkzNDIzMTY4LCJuYmYiOjE0OTM0MjMxNjgsImV4cCI6MTQ5MzQ2Njk1MSwiYW1yIjpbInB3ZCJdLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJzdWIiOiJEVXpYbkdKMDJIUk0zRW5pbDFxdjZCakxTNUllQy0tQ2ZpbzRxS1MzNEc4IiwidGlkIjoiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwidW5pcXVlX25hbWUiOiJuYXZ5YUBkZG9iYWxpYW5vdXRsb29rLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidXRpIjoieEN3ZnpoYS1QMFdKUU9MeENHZ0tBQSIsInZlciI6IjEuMCJ9."
}

Przykład odpowiedzi na błąd

Punkt końcowy tokenu Azure AD zwraca odpowiedź o błędzie podczas próby uzyskania tokenu dostępu dla podrzędnego interfejsu API ustawionego przy użyciu zasad dostępu warunkowego (na przykład uwierzytelniania wieloskładnikowego). Usługa warstwy środkowej powinna spowodować wyświetlenie tego błędu w aplikacji klienckiej, aby aplikacja kliencka mogła zapewnić interakcję użytkownika w celu spełnienia zasad dostępu warunkowego.

{
    "error":"interaction_required",
    "error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access 'bf8d80f9-9098-4972-b203-500f535113b1'.\r\nTrace ID: b72a68c3-0926-4b8e-bc35-3150069c2800\r\nCorrelation ID: 73d656cf-54b1-4eb2-b429-26d8165a52d7\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"b72a68c3-0926-4b8e-bc35-3150069c2800",
    "correlation_id":"73d656cf-54b1-4eb2-b429-26d8165a52d7",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"9ab03e19-ed42-4168-b6b7-7001fb3e933a\"]}}}"
}

Uzyskiwanie dostępu do zabezpieczonego zasobu przy użyciu tokenu dostępu

Usługa warstwy środkowej może używać uzyskanego tokenu dostępu, aby wysyłać uwierzytelnione żądania do podrzędnego internetowego interfejsu API, ustawiając token w nagłówku Authorization .

Przykład

GET /me?api-version=2013-11-08 HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw

Asercji SAML uzyskanych przy użyciu przepływu OAuth2.0 OBO

Niektóre usługi internetowe oparte na protokole OAuth muszą uzyskiwać dostęp do innych interfejsów API usługi internetowej, które akceptują asercji SAML w nieinterakcyjnych przepływach. Usługa Azure Active Directory może zapewnić asercji SAML w odpowiedzi na przepływ On-Behalf-Of, który używa usługi internetowej opartej na protokole SAML jako zasobu docelowego.

Uwaga

Jest to standardowe rozszerzenie przepływu OAuth 2.0 On-Behalf-Of, które umożliwia aplikacji opartej na protokole OAuth2 dostęp do punktów końcowych interfejsu API usługi internetowej korzystających z tokenów SAML.

Porada

Podczas wywoływania usługi internetowej chronionej przez protokół SAML z aplikacji internetowej frontonu można po prostu wywołać interfejs API i zainicjować normalny przepływ uwierzytelniania interakcyjnego z istniejącą sesją użytkownika. Przepływ OBO musi być używany tylko wtedy, gdy wywołanie typu service-to-service wymaga tokenu SAML w celu zapewnienia kontekstu użytkownika.

Uzyskiwanie tokenu SAML przy użyciu żądania OBO z udostępnionym wpisem tajnym

Żądanie service-to-service dla asercji SAML zawiera następujące parametry:

Parametr Typ Opis
grant_type wymagane Typ żądania tokenu. W przypadku żądania, które używa JWT, wartość musi być urn:ietf:params:oauth:grant-type:jwt-bearer.
Potwierdzenia wymagane Wartość tokenu dostępu używanego w żądaniu.
client_id wymagane Identyfikator aplikacji przypisany do usługi wywołującej podczas rejestracji z Azure AD. Aby znaleźć identyfikator aplikacji w Azure Portal, wybierz pozycję Active Directory, wybierz katalog, a następnie wybierz nazwę aplikacji.
client_secret wymagane Klucz zarejestrowany dla usługi wywołującej w Azure AD. Ta wartość powinna zostać zanotowana w momencie rejestracji.
zasób wymagane Identyfikator URI aplikacji odbierającego usługi (zabezpieczony zasób). Jest to zasób, który będzie odbiorcą tokenu SAML. Aby znaleźć identyfikator URI identyfikatora aplikacji w Azure Portal, wybierz pozycję Active Directory i wybierz katalog. Wybierz nazwę aplikacji, wybierz pozycję Wszystkie ustawienia, a następnie wybierz pozycję Właściwości.
requested_token_use wymagane Określa sposób przetwarzania żądania. W przepływie On-Behalf-Of wartość musi być on_behalf_of.
requested_token_type wymagane Określa typ żądanego tokenu. Wartość może być urn:ietf:params:oauth:token-type:saml2 lub urn:ietf:params:oauth:token-type:saml1 w zależności od wymagań dostępu do zasobu.

Odpowiedź zawiera token SAML zakodowany w formacie UTF8 i Base64url.

  • SubjectConfirmationData dla asercji SAML pochodzącej z wywołania OBO: jeśli aplikacja docelowa wymaga wartości adresata w obiekcie SubjectConfirmationData, wartość musi być adresem URL odpowiedzi innej niż wieloznaczny w konfiguracji aplikacji zasobu.

  • Węzeł SubjectConfirmationData: węzeł nie może zawierać atrybutu InResponseTo , ponieważ nie jest częścią odpowiedzi SAML. Aplikacja odbierając token SAML musi być w stanie zaakceptować asercji SAML bez atrybutu InResponseTo .

  • Zgoda: zgoda musi zostać udzielona w celu otrzymania tokenu SAML zawierającego dane użytkownika w przepływie protokołu OAuth. Aby uzyskać informacje na temat uprawnień i uzyskiwania zgody administratora, zobacz Uprawnienia i zgoda w punkcie końcowym usługi Azure Active Directory w wersji 1.0.

Odpowiedź z asercją SAML

Parametr Opis
token_type Wskazuje wartość typu tokenu. Jedynym typem, który obsługuje Azure AD, jest bearer. Aby uzyskać więcej informacji na temat tokenów elementu nośnego, zobacz OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750).
scope Zakres dostępu udzielony w tokenie.
expires_in Czas ważności tokenu dostępu (w sekundach).
expires_on Czas wygaśnięcia tokenu dostępu. Data jest reprezentowana jako liczba sekund od 1970-01-01T0:0:0Z UTC do czasu wygaśnięcia. Ta wartość służy do określania okresu istnienia buforowanych tokenów.
zasób Identyfikator URI aplikacji odbierającego usługi (zabezpieczony zasób).
access_token Parametr, który zwraca asercji SAML.
refresh_token Token odświeżania. Usługa wywołująca może użyć tego tokenu, aby zażądać innego tokenu dostępu po wygaśnięciu bieżącej asercji SAML.
  • token_type: Bearer
  • expires_in: 3296
  • ext_expires_in: 0
  • expires_on: 1529627844
  • Zasobów: https://api.contoso.com
  • access_token: <asercji SAML>
  • issued_token_type: urn:ietf:params:oauth:token-type:saml2
  • refresh_token: <Odświeżanie tokenu>

Ograniczenia klienta

Klienci publiczni z adresami URL odpowiedzi z symbolami wieloznacznymi nie mogą używać elementu id_token dla przepływów OBO. Jednak poufny klient nadal może zrealizować tokeny dostępu uzyskane za pośrednictwem niejawnego przepływu udzielania, nawet jeśli klient publiczny ma zarejestrowany identyfikator URI przekierowania z symbolami wieloznacznymi.

Następne kroki

Dowiedz się więcej na temat protokołu OAuth 2.0 i innego sposobu przeprowadzania uwierzytelniania typu service-to-service korzystającego z poświadczeń klienta: