Opis dostępu tylko do aplikacji
Gdy aplikacja uzyskuje bezpośredni dostęp do zasobu, takiego jak program Microsoft Graph, jego dostęp nie jest ograniczony do plików ani operacji dostępnych dla żadnego pojedynczego użytkownika. Aplikacja wywołuje interfejsy API bezpośrednio przy użyciu własnej tożsamości, a użytkownik lub aplikacja z uprawnieniami administratora musi autoryzować go do uzyskiwania dostępu do zasobów. Ten scenariusz jest dostępem tylko do aplikacji.
Kiedy należy używać dostępu tylko do aplikacji?
W większości przypadków dostęp tylko do aplikacji jest szerszy i bardziej zaawansowany niż dostęp delegowany, dlatego w razie potrzeby należy używać dostępu tylko do aplikacji. Zazwyczaj jest to właściwy wybór, jeśli:
- Aplikacja musi działać w zautomatyzowany sposób bez danych wejściowych użytkownika. Na przykład codzienny skrypt, który sprawdza wiadomości e-mail z określonych kontaktów i wysyła automatyczne odpowiedzi.
- Aplikacja musi uzyskiwać dostęp do zasobów należących do wielu różnych użytkowników. Na przykład aplikacja do ochrony przed utratą danych lub kopii zapasowej może wymagać pobrania wiadomości z wielu różnych kanałów czatu, z których każdy ma różnych uczestników.
- Możesz samodzielnie przechowywać poświadczenia lokalnie i zezwolić aplikacji na logowanie się "jako" użytkownika lub administratora.
Z kolei nigdy nie należy używać dostępu tylko do aplikacji, w którym użytkownik zwykle loguje się do zarządzania własnymi zasobami. Te typy scenariuszy muszą używać dostępu delegowanego, aby być najmniej uprzywilejowanym.
Autoryzowanie aplikacji w celu tworzenia wywołań tylko aplikacji
Aby wykonać wywołania tylko aplikacji, musisz przypisać aplikację kliencją odpowiednie role aplikacji. Role aplikacji są również określane jako uprawnienia tylko do aplikacji. Są to role aplikacji , ponieważ udzielają dostępu tylko w kontekście aplikacji zasobów, która definiuje rolę.
Aby na przykład przeczytać listę wszystkich zespołów utworzonych w organizacji, musisz przypisać aplikację do roli aplikacji programu Microsoft Graph Team.ReadBasic.All . Ta rola aplikacji umożliwia odczytywanie tych danych, gdy program Microsoft Graph jest aplikacją zasobów. To przypisanie nie powoduje przypisania aplikacji klienckiej do roli usługi Teams, która może zezwalać na wyświetlanie tych danych za pośrednictwem innych usług.
Jako deweloper musisz skonfigurować wszystkie wymagane uprawnienia tylko do aplikacji, nazywane również rolami aplikacji w rejestracji aplikacji. Możesz skonfigurować żądane uprawnienia tylko do aplikacji za pośrednictwem witryny Azure Portal lub programu Microsoft Graph. Dostęp tylko do aplikacji nie obsługuje zgody dynamicznej, więc nie można żądać indywidualnych uprawnień ani zestawów uprawnień w czasie wykonywania.
Po skonfigurowaniu wszystkich wymaganych uprawnień aplikacja musi uzyskać zgodę administratora, aby uzyskać do niej dostęp do zasobów. Na przykład tylko użytkownicy z co najmniej rolą Administrator ról uprzywilejowanych mogą udzielać uprawnień tylko aplikacji (ról aplikacji) dla interfejsu API programu Microsoft Graph. Użytkownicy z innymi rolami administratora, takimi jak Administrator aplikacji i Administrator aplikacji w chmurze, mogą udzielać uprawnień tylko do aplikacji dla innych zasobów.
Użytkownicy administracyjni mogą udzielać uprawnień tylko do aplikacji przy użyciu witryny Azure Portal lub programowo tworząc granty za pośrednictwem interfejsu API programu Microsoft Graph. Możesz również monitować o interakcyjne wyrażenie zgody z poziomu aplikacji, ale ta opcja nie jest preferowana, ponieważ dostęp tylko do aplikacji nie wymaga użytkownika.
Użytkownicy konsumentów z kontami Microsoft, takimi jak konta Outlook.com lub Xbox Live, nigdy nie mogą autoryzować dostępu tylko do aplikacji.
Zawsze przestrzegaj zasady najniższych uprawnień: nigdy nie należy żądać ról aplikacji, 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 identyfikować użytkowników bez odczytywania szczegółowych informacji o profilu, należy zażądać bardziej ograniczonej roli aplikacji Microsoft Graph User.ReadBasic.All zamiast User.Read.All.
Projektowanie i publikowanie ról aplikacji dla usługi zasobów
Jeśli tworzysz usługę w usłudze Microsoft Entra ID, która uwidacznia interfejsy API dla innych klientów do wywołania, możesz chcieć obsługiwać automatyczny dostęp z rolami aplikacji (uprawnienia tylko do aplikacji). Role aplikacji można zdefiniować w sekcji Role aplikacji rejestracji aplikacji w centrum administracyjnym firmy Microsoft Entra. Aby uzyskać więcej informacji na temat tworzenia ról aplikacji, zobacz Deklarowanie ról dla aplikacji.
W przypadku uwidaczniania ról aplikacji dla innych użytkowników podaj jasne opisy scenariusza dla administratora, który będzie je przypisywać. Role aplikacji powinny być zwykle tak wąskie, jak to możliwe i obsługiwać określone scenariusze funkcjonalne, ponieważ dostęp tylko do aplikacji nie jest ograniczony przez prawa użytkownika. Unikaj uwidaczniania pojedynczej roli, która udziela pełnego read lub pełnego read/write dostępu do wszystkich interfejsów API i zasobów, które zawiera twoja usługa.
Uwaga
Role aplikacji (uprawnienia tylko do aplikacji) można również skonfigurować tak, aby obsługiwały przypisywanie do użytkowników i grup. Upewnij się, że role aplikacji są poprawnie skonfigurowane dla zamierzonego scenariusza dostępu. Jeśli zamierzasz używać ról aplikacji interfejsu API do uzyskiwania dostępu tylko do aplikacji, wybierz aplikacje jako jedyne dozwolone typy składowe podczas tworzenia ról aplikacji.
Jak działa dostęp tylko do aplikacji?
Najważniejszą rzeczą, którą należy pamiętać o dostępie tylko do aplikacji, jest to, że aplikacja wywołująca działa we własnym imieniu i jako własna tożsamość. Brak interakcji użytkownika. Jeśli aplikacja została przypisana do danej roli aplikacji dla zasobu, aplikacja ma w pełni nieograniczony dostęp do wszystkich zasobów i operacji zarządzanych przez daną rolę aplikacji.
Po przypisaniu aplikacji do co najmniej jednej roli aplikacji (uprawnienia tylko do aplikacji) może zażądać tokenu tylko dla aplikacji z identyfikatora Entra firmy Microsoft przy użyciu przepływu poświadczeń klienta lub dowolnego innego obsługiwanego przepływu uwierzytelniania. Przypisane role są dodawane do roles oświadczenia tokenu dostępu aplikacji.
W niektórych scenariuszach tożsamość aplikacji może określić, czy udzielono dostępu, podobnie jak prawa użytkownika w wywołaniu delegowanym. Na przykład Application.ReadWrite.OwnedBy rola aplikacji przyznaje aplikacji możliwość zarządzania jednostkami usługi, których właścicielem jest sama aplikacja.
Przykład dostępu tylko do aplikacji — automatyczne powiadomienie e-mail za pośrednictwem programu Microsoft Graph
W poniższym przykładzie przedstawiono realistyczny scenariusz automatyzacji.
Alicja chce powiadomić zespół pocztą e-mail za każdym razem, gdy folder raportowania podziału znajdujący się w udziale plików systemu Windows rejestruje nowy dokument. Alicja tworzy zaplanowane zadanie uruchamiające skrypt programu PowerShell w celu sprawdzenia folderu i znalezienia nowych plików. Następnie skrypt wysyła wiadomość e-mail przy użyciu skrzynki pocztowej chronionej przez interfejs API zasobów, Microsoft Graph.
Skrypt jest uruchamiany bez interakcji użytkownika, dlatego system autoryzacji sprawdza tylko autoryzację aplikacji. Usługa Exchange Online sprawdza, czy klient wykonujący wywołanie otrzymał uprawnienie aplikacji (rolę aplikacji) Mail.Send przez administratora. Jeśli Mail.Send nie zostanie udzielona aplikacji, żądanie usługi Exchange Online zakończy się niepowodzeniem.
| POST /users/{id}/{userPrincipalName}/sendMail | Aplikacja kliencka otrzymała wiadomość Mail.Send | Nie udzielono aplikacji klienckiej Mail.Send |
|---|---|---|
| Skrypt używa skrzynki pocztowej Alice do wysyłania wiadomości e-mail. | 200 — Udzielono dostępu. Administrator zezwolił aplikacji na wysyłanie wiadomości e-mail jako dowolny użytkownik. | 403 — Brak autoryzacji. Administrator nie zezwolił temu klientowi na wysyłanie wiadomości e-mail. |
| Skrypt tworzy dedykowaną skrzynkę pocztową do wysyłania wiadomości e-mail. | 200 — Udzielono dostępu. Administrator zezwolił aplikacji na wysyłanie wiadomości e-mail jako dowolny użytkownik. | 403 — Brak autoryzacji. Administrator nie zezwolił temu klientowi na wysyłanie wiadomości e-mail. |
Podany przykład jest prostą ilustracją autoryzacji aplikacji. Produkcyjna usługa Exchange Online obsługuje wiele innych scenariuszy dostępu, takich jak ograniczanie uprawnień aplikacji do określonych skrzynek pocztowych usługi Exchange Online.