Opis dostępu delegowanego
Gdy użytkownik loguje się do aplikacji i używa go do uzyskania dostępu do innego zasobu, takiego jak Microsoft Graph, aplikacja najpierw będzie musiała poprosić o pozwolenie na dostęp do tego zasobu w imieniu użytkownika. Ten typowy scenariusz jest nazywany dostępem delegowanym.
Dlaczego należy używać dostępu delegowanego?
Użytkownicy często używają różnych aplikacji do uzyskiwania dostępu do danych z usług w chmurze. Na przykład ktoś może chcieć użyć ulubionej aplikacji czytnika plików PDF do wyświetlania plików przechowywanych w usłudze OneDrive. Innym przykładem może być aplikacja biznesowa firmy, która może pobierać udostępnione informacje o swoich współpracownikach, aby mogli łatwo wybierać recenzentów dla żądania. W takich przypadkach aplikacja kliencka, czytnik PLIKÓW PDF lub narzędzie do zatwierdzania żądań firmy musi być autoryzowana do uzyskiwania dostępu do tych danych w imieniu użytkownika, który zalogował się do aplikacji.
Użyj dostępu delegowanego za każdym razem, gdy chcesz zezwolić zalogowanym użytkownikowi na pracę z własnymi zasobami lub zasobami, do których mogą uzyskiwać dostęp. Niezależnie od tego, czy jest to administrator konfigurujący zasady dla całej organizacji, czy użytkownik usuwający wiadomość e-mail w skrzynce odbiorczej, wszystkie scenariusze obejmujące akcje użytkownika powinny używać delegowanego dostępu.
Z kolei dostęp delegowany jest zwykle złym wyborem w scenariuszach, które muszą działać bez zalogowanego użytkownika, takiego jak automatyzacja. Może to być również słaby wybór scenariuszy obejmujących dostęp do zasobów wielu użytkowników, takich jak zapobieganie utracie danych lub tworzenie kopii zapasowych. Rozważ użycie dostępu tylko do aplikacji dla tych typów operacji.
Żądanie zakresów jako aplikacji klienckiej
Aplikacja musi poprosić użytkownika o przyznanie określonego zakresu lub zestawu zakresów dla aplikacji zasobów, do której chcesz uzyskać dostęp. Zakresy mogą być również określane jako uprawnienia delegowane. Te zakresy opisują zasoby i operacje, które aplikacja chce wykonać w imieniu użytkownika. Jeśli na przykład aplikacja ma wyświetlać użytkownikowi listę ostatnio odebranych wiadomości e-mail i wiadomości czatu, możesz poprosić użytkownika o zgodę na program Microsoft Graph Mail.Read i Chat.Read zakresy.
Gdy aplikacja zażąda zakresu, użytkownik lub administrator będzie musiał udzielić żądanego dostępu. Użytkownicy konsumentów z kontami Microsoft, takimi jak konta Outlook.com lub Xbox Live, zawsze mogą udzielać zakresów dla siebie. Użytkownicy organizacyjni z kontami Microsoft Entra mogą lub nie mogą mieć możliwości udzielania zakresów w zależności od ustawień organizacji. Jeśli użytkownik organizacji nie może wyrazić zgody na zakresy bezpośrednio, musi poprosić administratora organizacji o zgodę na nie.
Zawsze przestrzegaj zasady najniższych uprawnień: nigdy nie należy żądać zakresów, których aplikacja nie potrzebuje. Ta zasada pomaga ograniczyć ryzyko bezpieczeństwa w przypadku naruszenia zabezpieczeń aplikacji i ułatwia administratorom udzielanie dostępu do aplikacji. Jeśli na przykład aplikacja musi wyświetlić tylko listę czatów, do których należy użytkownik, ale nie musi wyświetlać samych wiadomości czatów, należy zażądać bardziej ograniczonego zakresu programu Microsoft Graph Chat.ReadBasic zamiast Chat.Read. Aby uzyskać więcej informacji na temat zakresów openID, zobacz Zakresy OpenID.
Projektowanie i publikowanie zakresów dla usługi zasobów
Jeśli tworzysz interfejs API i chcesz zezwolić na dostęp delegowany w imieniu użytkowników, musisz utworzyć zakresy, których mogą zażądać inne aplikacje. Te zakresy powinny opisywać akcje lub zasoby dostępne dla klienta. Podczas projektowania zakresów należy wziąć pod uwagę scenariusze deweloperskie.
Token do siebie
W scenariuszu, w którym:
- Aplikacja zasobów i aplikacja kliencka są takie same.
- Aplikacja nie ma zarejestrowanego internetowego interfejsu API.
- Aplikacja żąda tokenu dla delegowanego uprawnienia, które uwidacznia się
Żadna zgoda nie będzie potrzebna ani wyświetlana dla tego żądania tokenu. Ponadto aplikacje utworzone w ramach dzierżawy i żądanie tokenu do siebie mogą zostać wywnioskowane, aby mieć już dostęp do danych profilu i automatycznie otrzymają dostęp do profilu.
Jak działa dostęp delegowany?
Najważniejszą rzeczą, aby pamiętać o delegowanym dostępie, jest to, że zarówno aplikacja kliencka, jak i zalogowany użytkownik muszą być prawidłowo autoryzowane. Udzielanie zakresu nie wystarczy. Jeśli aplikacja kliencka nie ma odpowiedniego zakresu lub użytkownik nie ma wystarczających praw do odczytu lub modyfikowania zasobu, wywołanie zakończy się niepowodzeniem.
- Autoryzacja aplikacji klienckiej — aplikacje klienckie są autoryzowane, udzielając zakresów. Gdy aplikacja kliencka otrzymuje zakres przez użytkownika lub administratora w celu uzyskania dostępu do niektórych zasobów, zostanie ona zarejestrowana w identyfikatorze Entra firmy Microsoft. Wszystkie delegowane tokeny dostępu, które są żądane przez klienta w celu uzyskania dostępu do zasobu w imieniu odpowiedniego użytkownika, będą następnie zawierać wartości oświadczeń tych zakresów w oświadczeniu
scp. Aplikacja zasobów sprawdza to oświadczenie, aby określić, czy aplikacja kliencka otrzymała prawidłowy zakres wywołania. - Autoryzacja użytkownika — użytkownicy są autoryzowani przez wywoływany zasób. Aplikacje zasobów mogą używać co najmniej jednego systemu do autoryzacji użytkownika, takich jak kontrola dostępu oparta na rolach, relacje własności/członkostwa, listy kontroli dostępu lub inne kontrole. Na przykład identyfikator Entra firmy Microsoft sprawdza, czy użytkownik został przypisany do roli zarządzania aplikacjami lub administratora ogólnego przed zezwoleniem im na usunięcie aplikacji organizacji, ale także umożliwia wszystkim użytkownikom usuwanie własnych aplikacji. Podobnie usługa SharePoint Online sprawdza, czy użytkownik ma odpowiednie uprawnienia właściciela lub czytelnika do pliku przed zezwoleniem użytkownikowi na jego otwarcie.
Przykład dostępu delegowanego — OneDrive za pośrednictwem programu Microsoft Graph
Rozważmy następujący przykład:
Alicja chce użyć aplikacji klienckiej do otwarcia pliku chronionego przez interfejs API zasobów, Microsoft Graph. W przypadku autoryzacji użytkownika usługa OneDrive sprawdzi, czy plik jest przechowywany na dysku Alicji. Jeśli jest on przechowywany na dysku innego użytkownika, usługa OneDrive odmówi żądania Alicji jako nieautoryzowanego, ponieważ Alicja nie ma prawa do odczytu dysków innych użytkowników.
W przypadku autoryzacji aplikacji klienckiej usługa OneDrive sprawdzi, czy klient wykonujący wywołanie otrzymał Files.Read zakres w imieniu zalogowanego użytkownika. W takim przypadku zalogowany użytkownik to Alice. Jeśli Files.Read aplikacja Alice nie została udzielona, usługa OneDrive również zakończy się niepowodzeniem żądania.
| GET /drives/{id}/files/{id} | Zakres udzielony Files.Read aplikacji klienckiej dla Alicji |
Aplikacja kliencka nie otrzymała Files.Read zakresu dla Alicji |
|---|---|---|
| Dokument znajduje się w usłudze OneDrive Alicji. | 200 — Udzielono dostępu. | 403 — Brak autoryzacji. Alicja (lub jej administrator) nie zezwoliła temu klientowi na odczytywanie swoich plików. |
| Dokument znajduje się w usłudze OneDrive innego użytkownika*. | 403 — Brak autoryzacji. Alicja nie ma uprawnień do odczytu tego pliku. Mimo że klient otrzymał Files.Read go, powinien zostać odrzucony podczas działania w imieniu Alicji. |
403 — Brak autoryzacji. Alice nie ma uprawnień do odczytu tego pliku, a klient nie może odczytywać plików, do których ma dostęp. |
Podany przykład jest uproszczony w celu zilustrowania delegowanej autoryzacji. Produkcyjna usługa OneDrive obsługuje wiele innych scenariuszy dostępu, takich jak pliki udostępnione.