Werken met OAuth-tokens in Azure-app Service-verificatie
In dit artikel wordt beschreven hoe u met OAuth-tokens kunt werken terwijl u gebruikmaakt van de ingebouwde verificatie en autorisatie in App Service.
Tokens ophalen in toepassingscode
Vanuit uw servercode worden de providerspecifieke tokens geïnjecteerd in de aanvraagheader, zodat u ze eenvoudig kunt openen. De volgende tabel geeft de mogelijke namen van tokenheaders aan:
| Provider | Koptekstnamen |
|---|---|
| Microsoft Entra | X-MS-TOKEN-AAD-ID-TOKEN X-MS-TOKEN-AAD-ACCESS-TOKEN X-MS-TOKEN-AAD-EXPIRES-ON X-MS-TOKEN-AAD-REFRESH-TOKEN |
| Facebook-token | X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN X-MS-TOKEN-FACEBOOK-EXPIRES-ON |
X-MS-TOKEN-GOOGLE-ID-TOKEN X-MS-TOKEN-GOOGLE-ACCESS-TOKEN X-MS-TOKEN-GOOGLE-EXPIRES-ON X-MS-TOKEN-GOOGLE-REFRESH-TOKEN |
|
| X | X-MS-TOKEN-TWITTER-ACCESS-TOKEN X-MS-TOKEN-TWITTER-ACCESS-TOKEN-SECRET |
Notitie
Verschillende taalframeworks kunnen deze headers presenteren aan de app-code in verschillende indelingen, zoals kleine letters of titelcases.
Verzend vanuit uw clientcode (zoals een mobiele app of JavaScript in de browser) een HTTP-aanvraag GET naar /.auth/me (tokenarchief moet zijn ingeschakeld). De geretourneerde JSON heeft de providerspecifieke tokens.
Notitie
Toegangstokens zijn bedoeld voor toegang tot providerbronnen, dus ze zijn alleen aanwezig als u uw provider configureert met een clientgeheim. Zie Toegangstokens vernieuwen om te zien hoe u vernieuwingstokens kunt ophalen.
Verificatietokens vernieuwen
Wanneer het toegangstoken van uw provider (niet het sessietoken) verloopt, moet u de gebruiker opnieuw verifiëren voordat u dat token opnieuw gebruikt. U kunt het verlopen van tokens voorkomen door een GET aanroep uit te voeren naar het /.auth/refresh eindpunt van uw toepassing. Wanneer deze wordt aangeroepen, vernieuwt App Service automatisch de toegangstokens in het tokenarchief voor de geverifieerde gebruiker. Volgende aanvragen voor tokens door uw app-code krijgen de vernieuwde tokens. Het tokenarchief moet echter wel vernieuwingstokens bevatten voor uw provider om het token te vernieuwen. De manier om vernieuwingstokens op te halen, wordt door elke provider gedocumenteerd, maar de volgende lijst is een kort overzicht:
Google: Voeg een
access_type=offlinequeryreeksparameter toe aan uw/.auth/login/googleAPI-aanroep. Zie Google Refresh Tokens voor meer informatie.Facebook: biedt geen vernieuwingstokens. Tokens met een lange levensduur verlopen over 60 dagen (zie Facebook-verlooptijd en uitbreiding van toegangstokens).
X: Toegangstokens verlopen niet (zie veelgestelde vragen over OAuth).
Voer de volgende stappen uit:https://resources.azure.com
Selecteer lezen/schrijven boven aan de pagina.
Navigeer in de linkerbrowser naar abonnementen<>subscription_name>>resourceGroups><resource_group_name>>providers>Microsoft.Web>sites><app_name>>config authsettingsV2.>
Klik op Bewerken.
Wijzig de volgende eigenschap.
"identityProviders": { "azureActiveDirectory": { "login": { "loginParameters": ["scope=openid profile email offline_access"] } } }Klik op Put.
Notitie
Het bereik waarmee u een vernieuwingstoken krijgt, is offline_access. Bekijk hoe deze wordt gebruikt in de zelfstudie: gebruikers end-to-end verifiëren en autoriseren in Azure-app Service. De andere bereiken worden standaard aangevraagd door App Service. Zie OpenID Connect-bereiken voor meer informatie over deze standaardbereiken.
Zodra uw provider is geconfigureerd, kunt u het vernieuwingstoken en de verlooptijd voor het toegangstoken in het tokenarchief vinden.
Als u uw toegangstoken op elk gewenst moment wilt vernieuwen, belt /.auth/refresh u in elke taal. In het volgende codefragment wordt jQuery gebruikt om uw toegangstokens te vernieuwen vanuit een JavaScript-client.
function refreshTokens() {
let refreshUrl = "/.auth/refresh";
$.ajax(refreshUrl) .done(function() {
console.log("Token refresh completed successfully.");
}) .fail(function() {
console.log("Token refresh failed. See application logs for details.");
});
}
Als een gebruiker de machtigingen die aan uw app zijn verleend, intrekt, kan uw aanroep /.auth/me mislukken met een 403 Forbidden antwoord. Als u fouten wilt diagnosticeren, controleert u de toepassingslogboeken op details.
Respijtperiode voor verlooptijd van sessietoken uitbreiden
De geverifieerde sessie verloopt na 8 uur. Nadat een geverifieerde sessie is verlopen, is er standaard een respijtperiode van 72 uur. Binnen deze respijtperiode mag u het sessietoken vernieuwen met App Service zonder de gebruiker opnieuw te verifiëren. U kunt gewoon bellen /.auth/refresh wanneer uw sessietoken ongeldig wordt en u hoeft het verloop van het token niet zelf bij te houden. Zodra de respijtperiode van 72 uur is verstreken, moet de gebruiker zich opnieuw aanmelden om een geldig sessietoken op te halen.
Als 72 uur niet genoeg tijd voor u is, kunt u dit verloopvenster verlengen. Het verlengen van de vervaldatum gedurende een lange periode kan aanzienlijke gevolgen hebben voor de beveiliging (bijvoorbeeld wanneer een verificatietoken wordt gelekt of gestolen). U moet deze dus op de standaardwaarde van 72 uur laten staan of de verlengingsperiode instellen op de kleinste waarde.
Als u het standaardverloopvenster wilt uitbreiden, voert u de volgende opdracht uit in Cloud Shell.
az webapp auth update --resource-group <group_name> --name <app_name> --token-refresh-extension-hours <hours>
Notitie
De respijtperiode is alleen van toepassing op de geverifieerde App Service-sessie, niet op de tokens van de id-providers. Er is geen respijtperiode voor de verlopen providertokens.