Förstå API-auktorisering och cachelagring av token
Företagsportalens design omfattar läsning av den inloggade användarens profil från Microsoft Graph. Autentisering identifierar användaren till portalen, men ett API-anrop behöver också en åtkomsttoken med lämpliga behörigheter.
I den här lektionen beskrivs behörighetstyper, omfång och ett illustrativt MSAL4J-tokencachemönster. Det förutsätter inte att ett program eller en inloggad session körs.
API-behörigheter och omfång
Ett skyddat API definierar behörigheter för dess funktioner och data. Microsoft Graph har till exempel olika behörigheter för att läsa en profil, läsa en kalender och skicka e-post. Ett program begär endast de behörigheter som krävs för den avsedda åtgärden.
Microsoft Entra ID stöder två behörighetstyper:
| Behörighetstyp | Kontext | Samtycke |
|---|---|---|
| Delegerade behörigheter | Programmet agerar för en inloggad användares räkning. Åtkomsten begränsas av de beviljade behörigheterna och användarens åtkomst. | En användare eller auktoriserad administratör kan bevilja medgivande, beroende på behörighet och klientorganisationsprincip. |
| Programbehörigheter | Programmet fungerar som sig självt utan en inloggad användare, till exempel en bakgrundstjänst. | Administratörsmedgivande krävs. |
Portalen använder delegerade behörigheter User.Read för att läsa den inloggade användarens profil. Den här behörigheten beviljar inte åtkomst till alla användares data eller orelaterade resurser, till exempel kalendrar.
Omfång beskriver den begärda åtkomsten
I en delegerad auktoriseringsbegäran uttrycker OAuth 2.0-omfången behörigheterna för programbegäranden. Ett omfång kan identifiera både resursen och behörigheten. till exempel https://graph.microsoft.com/Calendars.Read begär kalenderläsningsbehörighet för Microsoft Graph.
Exemplen använder det enskilda omfånget User.Read. För Microsoft Graph omfång kan resursidentifieraren utelämnas, så detta representerar https://graph.microsoft.com/User.Read. Mer information finns i Omfång och behörigheter.
Konfigurerade API-behörigheter, begärda omfång och medgivande är distinkta. Att lägga till en API-behörighet till en appregistrering beviljar inte självt medgivande eller ändrar de omfång som begärs av programmets kod.
En åtkomsttoken är specifik för dess API
En åtkomsttoken är avsedd för en viss resurs. En token för Microsoft Graph är inte utbytbar med en token för ett annat API och en ID-token ersätter inte en API-åtkomsttoken.
MSAL4J hämtar och cachelagrar token. Programmet använder token för den avsedda resursen i stället för att parsa den för att göra antaganden om den inloggade användarens identitet eller behandla den som en återanvändbar auktoriseringskod.
Illustrativt förvärv av tyst token
För senare begäranden kan ett webbprogram be MSAL om en token utan att skicka användaren via en annan inloggningsinteraktion. Följande fragment är anpassat från referensexemplets AuthHelper. Den visar hur du återställer en sessionsassocierad cache och begär en token för ett konto som redan representeras i den kontexten.
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 identifierar det begärda omfånget och kontot. I det här exemplet Config.SCOPES innehåller User.Read, och context tillhandahåller kontot och serialiserad cache som är associerad med den autentiserade sessionen. Det här är hjälptexter för exempelapplikationer, inte värden som den lärande behöver få fram.
När cacheminnet har återställts acquireTokenSilently försöker du uppfylla begäran utan användarinteraktion. Den kan returnera en användbar cachelagrad åtkomsttoken eller använda en cachelagrad uppdateringstoken när det är tillämpligt. "Tyst" betyder inte nödvändigtvis att ingen nätverksbegäran inträffar.
Det här fragmentet utelämnar den omgivande cachepersistenceen och undantagshanteringen. Om MSAL anger att användarinteraktion krävs startar webbprogrammet en ny auktoriseringsbegäran och bearbetar det resulterande återanropet. Den löser inte in den gamla auktoriseringskoden igen. Andra fel, till exempel nätverks- eller konfigurationsfel, behöver lämplig felhantering i stället för en ovillkorlig inloggningsloop.
Tokencache- och sessionsdata innehåller känslig information. Ett fullständigt program måste skydda dessa data, associera dem med rätt konto och session och spara cacheändringar på rätt sätt.
Tolka resultatet före API-anropet
Lyckat tokenförvärv genererar en IAuthenticationResult som innehåller åtkomsttoken och information om dess livslängd och kontokontext. För en Microsoft Graph begäran tillhandahåller programmet Graph-åtkomsttoken till sin HTTP-klient eller Graph-autentiseringsprovider.
MSAL4J läser inte en användares profil bara genom att hämta den token. Den separata API-begäran utför dataåtgärden.
Microsoft Graph tillhandahåller resursen
Microsoft Graph exponerar Microsoft molndata och -tjänster via https://graph.microsoft.com. Slutpunkten /v1.0/me representerar den inloggade användaren och kräver en delegerad användarkontext.
Nästa avsnitt undersöker ett exempel på en begäran till den slutpunkten och motsvarande begäran via Java SDK för Graph. Översikten över Microsoft Graph beskriver det bredare API:et.