Omówienie autoryzacji interfejsu API i buforowania tokenów
Projekt portalu firmy obejmuje odczytywanie profilu zalogowanego użytkownika z Microsoft Graph. Uwierzytelnianie identyfikuje użytkownika w portalu, ale wywołanie interfejsu API wymaga również tokenu dostępu z odpowiednimi uprawnieniami.
Ten moduł wyjaśnia typy uprawnień, zakresy i przykładowy wzorzec pamięci podręcznej tokenów MSAL4J. Nie zakłada się, że aplikacja lub sesja logowania jest uruchomiona.
Uprawnienia i zakresy interfejsu API
Chroniony interfejs API definiuje uprawnienia do jego funkcjonalności i danych. Microsoft Graph, na przykład, ma różne uprawnienia do odczytywania profilu, odczytywania kalendarza i wysyłania wiadomości e-mail. Aplikacja żąda tylko uprawnień wymaganych do jej zamierzonej operacji.
Microsoft Entra ID obsługuje dwa typy uprawnień:
| Typ uprawnień | Kontekst | Zgoda |
|---|---|---|
| Uprawnienia delegowane | Aplikacja działa w imieniu zalogowanego użytkownika. Dostęp jest ograniczony przez przyznane uprawnienia i dostęp użytkownika. | Użytkownik lub autoryzowany administrator może udzielić zgody w zależności od uprawnień i zasad dzierżawy. |
| Uprawnienia aplikacji | Aplikacja działa samodzielnie, bez zalogowanego użytkownika, na przykład jako usługa działająca w tle. | Wymagana jest zgoda administratora. |
Ten portal używa delegowanych uprawnień User.Read do odczytu profilu zalogowanego użytkownika. To uprawnienie nie udziela dostępu do danych każdego użytkownika ani niepowiązanych zasobów, takich jak kalendarze.
Zakresy opisują żądany dostęp
W żądaniu delegowanej autoryzacji zakresy OAuth 2.0 określają uprawnienia, o które wnioskuje aplikacja. Zakres może identyfikować zarówno zasób, jak i uprawnienie; na przykład https://graph.microsoft.com/Calendars.Read żąda uprawnień do odczytu kalendarza dla Microsoft Graph.
W przykładach użyto pojedynczego zakresu User.Read. W przypadku zakresów usługi Microsoft Graph można pominąć identyfikator zasobu, co odpowiada https://graph.microsoft.com/User.Read. Aby uzyskać więcej informacji, zobacz Zakresy i uprawnienia.
Skonfigurowane uprawnienia interfejsu API, żądane zakresy i zgoda są odrębne. Dodanie uprawnienia interfejsu API do rejestracji aplikacji nie daje zgody ani nie zmienia zakresów żądanych przez kod aplikacji.
Token dostępu jest przypisany do konkretnego interfejsu API
Token dostępu jest przeznaczony dla określonego zasobu. Tokenu przeznaczonego dla Microsoft Graph nie można używać zamiennie z tokenem dla innego interfejsu API, a token tożsamości nie zastępuje tokenu dostępu do interfejsu API.
Biblioteka MSAL4J uzyskuje tokeny i buforuje je. Aplikacja używa tokenu dla zamierzonego zasobu, a nie analizowania go w celu założeń dotyczących tożsamości zalogowanego użytkownika lub traktowania go jako kodu autoryzacji wielokrotnego użytku.
Ilustracyjne pozyskiwanie tokenów dyskretnych
W przypadku kolejnych żądań aplikacja internetowa może zażądać tokenu od biblioteki MSAL bez ponownego angażowania użytkownika w proces logowania. Poniższy fragment jest dostosowywany z przykładu referencyjnego AuthHelper. Ilustruje przywrócenie pamięci podręcznej skojarzonej z sesją i żądanie tokenu dla konta już reprezentowanego w tym kontekście.
final SilentParameters parameters = SilentParameters
.builder(Collections.singleton(Config.SCOPES), context.getAccount())
.build();
final ConfidentialClientApplication client = getConfidentialClientInstance();
client.tokenCache().deserialize(context.getTokenCache());
final IAuthenticationResult result = client.acquireTokenSilently(parameters).get();
SilentParameters identyfikuje żądany zakres i konto. W tym przykładzie Config.SCOPES zawiera User.Read, a context udostępnia konto i serializowaną pamięć podręczną skojarzone z uwierzytelnioną sesją. Są to przykładowe pomocniki aplikacji, a nie wartości, które należy uzyskać przez ucznia.
Po przywróceniu pamięci podręcznej acquireTokenSilently próbuje obsłużyć żądanie bez udziału użytkownika. Może zwrócić nadający się do użycia token dostępu z pamięci podręcznej lub, w stosownych przypadkach, użyć tokenu odświeżania z pamięci podręcznej. "Dyskretne" niekoniecznie oznacza, że żadne żądanie sieciowe nie występuje.
Ten fragment pomija otaczające utrwalanie pamięci podręcznej i obsługę wyjątków. Jeśli biblioteka MSAL wskazuje, że wymagana jest interakcja użytkownika, aplikacja internetowa uruchamia nowe żądanie autoryzacji i przetwarza otrzymane wywołanie zwrotne. Nie wykorzystuje ponownie starego kodu autoryzacyjnego. Inne błędy, takie jak błędy sieci lub konfiguracji, wymagają odpowiedniej obsługi błędów, a nie bezwarunkowej pętli logowania.
Pamięć podręczna tokenu i dane sesji zawierają poufne informacje. Kompletna aplikacja musi chronić te dane, skojarzyć je z prawidłowym kontem i sesją oraz odpowiednio utrwalać zmiany w pamięci podręcznej.
Interpretowanie wyniku przed wywołaniem interfejsu API
Pomyślne uzyskanie tokenu skutkuje uzyskaniem elementu IAuthenticationResult zawierającego token dostępu oraz informacje o okresie jego ważności i kontekście konta. W przypadku żądania Microsoft Graph aplikacja dostarcza token dostępu programu Graph do klienta HTTP lub dostawcy uwierzytelniania programu Graph.
Biblioteka MSAL4J nie odczytuje profilu użytkownika tylko przez uzyskanie tego tokenu. Oddzielne żądanie interfejsu API wykonuje operację danych.
Microsoft Graph udostępnia zasób
Microsoft Graph uwidacznia dane i usługi w chmurze Microsoft za pośrednictwem usługi https://graph.microsoft.com. Punkt /v1.0/me końcowy reprezentuje zalogowanego użytkownika i wymaga delegowanego kontekstu użytkownika.
W następnej części omówiono przykładowe żądanie kierowane do tego punktu końcowego oraz równoważne żądanie w pakiecie Java Graph SDK. Omówienie Microsoft Graph opisuje szerszy interfejs API.