Werken met OAuth-tokens in Azure-app Service-verificatie

In dit artikel wordt beschreven hoe u met OAuth-tokens kunt werken wanneer u de ingebouwde verificatie en autorisatie in Azure App Service gebruikt.

Tokens ophalen in toepassingscode

Vanuit uw servercode worden de providerspecifieke tokens geïnjecteerd in de aanvraagheader, zodat u deze eenvoudig kunt openen.

De volgende tabel bevat mogelijke namen van tokenheaders:

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
Google	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 programmeertaalframeworks kunnen deze headers op verschillende manieren aan de app-code presenteren, zoals in kleine letters of met een titelcase.

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 providerresources, dus ze zijn alleen aanwezig als u uw provider configureert met een clientgeheim.

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 korte samenvatting:

• Google: Voeg een access_type=offline queryreeksparameter toe aan uw /.auth/login/google API-aanroep. Zie Google Refresh Tokens voor meer informatie.

• Facebook: biedt geen vernieuwingstokens. Tokens met een lange levensduur verlopen over 60 dagen (zie Tokens voor langlevende toegang).

• X: Toegangstokens verlopen niet (zie veelgestelde vragen over OAuth).

• Microsoft: Voer in https://resources.azure.com de volgende stappen uit:

  1. Selecteer aan de bovenkant van het deelvenster De optie Lezen/Schrijven.

  2. Ga in het verkenner-menu naar abonnementen>abonnementsnaam>resourceGroups>resourcegroepnaam>providers>Microsoft.Web>sites>app-naam>config>authsettingsV2.

  3. Selecteer Bewerk.

  4. Wijzig de volgende eigenschap:

     "identityProviders": {
       "azureActiveDirectory": {
         "login": {
           "loginParameters": ["scope=openid profile email offline_access"]
         }
       }
     }
     

  5. Selecteer Put.

  Notitie

  Het bereik waarmee u een vernieuwingstoken krijgt, is offline_access. Bekijk hoe deze wordt gebruikt in de zelfstudie: gebruikers verifiëren en autoriseren die eindigen op Azure App Service. De andere toegangsniveaus worden standaard al door App Service aangevraagd. Zie OpenID Connect-bereiken voor meer informatie over deze standaardbereiken.

Nadat 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, roept u /.auth/refresh een willekeurige taal aan. 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, volgt bij standaardinstellingen 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 /.auth/refresh aanroepen wanneer uw sessietoken ongeldig wordt, en u hoeft de vervaldatum van het token niet zelf bij te houden. Wanneer 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 wordt aangeraden de instelling op de standaardwaarde van 72 uur te laten staan of de verlengingsperiode in te stellen op de kleinste waarde.

Als u het standaardverloopvenster wilt uitbreiden, voert u de volgende opdracht uit in Azure 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 bestaat geen respijtperiode voor verlopen providertokens.

Verwante inhoud

• Zelfstudie: Gebruikers end-to-end verifiëren en autoriseren