Expiration du jeton azure oauth

Les jetons d’actualisation sont couramment utilisés dans les scénarios d’autorisation basés sur OAuth. L’objectif du jeton d’actualisation est de récupérer le nouvel identifiant/jeton d’accès à partir du serveur d’autorisation, sans interaction de l’utilisateur. Dans des scénarios simples, une fois le jeton d’accès expiré, l’utilisateur est obligé de se réauthentifier afin d’obtenir un nouveau jeton. Avec les jetons d’actualisation, le jeton d’accès expiré peut être remplacé par un nouveau en arrière-plan, sans interaction de l’utilisateur.

L’utilisation de jetons d’actualisation améliore la sécurité de l’application. On pourrait penser que ce serait juste suffisant pour prolonger le délai d’expiration de l’identifiant/jeton d’accès. En le faisant durer longtemps, l’utilisateur évite souvent la ré-authentification. Cette approche peut exposer votre application à un risque accru d’interception et d’utilisation du jeton par un attaquant.

Une fois que le jeton d’identification/d’accès est récupéré du serveur Auth, il peut être utilisé jusqu’à son expiration sur le serveur de ressources (par exemple, le service de calendrier personnel). Risque d’interception de jetons et L’utilisation malveillante augmente à mesure que le même jeton d’identification/d’accès à longue durée de vie est utilisé encore et encore.

Avec un jeton d’accès de courte durée, le risque d’interception existe toujours, mais son utilisation malveillante peut être minimisée car il expire rapidement et ne peut plus être utilisé contre le serveur de ressources. Dans Azure AD B2C, la durée de vie par défaut du jeton d’accès est de 60 minutes et peut être configuré dans une plage de 5 minutes à 24 heures.

Outre les risques externes, les jetons d’accès à longue durée de vie exposent les ressources à des risques internes. Une fois que l’accès de l’utilisateur à une ressource spécifique est modifié ou révoqué, il est reflété uniquement dans le jeton d’accès généré après cette modification. Avec des jetons d’accès à longue durée, l’utilisateur peut conserver l’accès à la ressource pendant une longue période, même s’il a été modifié ou révoqué entre-temps.

Table des matières

Actualisation des jetons par le livre

Le diagramme ci-dessous présente comment le jeton de rafraîchissement peut être utilisé dans le flux d’octroi de code d’autorisation.

Pour obtenir le jeton d’actualisation à partir du serveur d’autorisation B2C Azure AD, la demande suivante doit être envoyée au point de terminaison /token

la réponse du serveur d’authentification inclut un nouveau jeton d’actualisation, un jeton d’accès ou un jeton d’identification (en fonction de l’étendue de la demande spécifiée).

Remarque 1

Le flux d’octroi du code d’autorisation est présenté à titre d’exemple. Notez que le jeton d’actualisation peut être utilisé dans d’autres flux OAuth, à l’exception du flux d’octroi implicite.

Note 2

Le jeton d’actualisation est chiffré lors de la génération et déchiffré par le serveur Auth une fois qu’il est utilisé. Sa charge utile est transparente pour l’application cliente et ne peut être comprise que par le serveur d’authentification.

Paramètres des jetons d’actualisation dans Azure AD B2C

Azure AD B2C régit les jetons d’actualisation et contrôle leur comportement. Le jeton d’actualisation peut être configuré à l’aide de 3 propriétés

refresh_token_lifetime_secs : décrit la durée de validité d’un jeton d’actualisation unique. Une fois que la durée de vie du jeton d’actualisation expire, il ne peut pas être utilisé pour collecter un nouveau jeton d’actualisation et sera refusé par le serveur d’authentification. La valeur minimale est de 24h, la valeur maximale est de 90 jours.
rolling_refresh_token_lifetime_secs – décrit la période pendant laquelle l’actualisation du jeton peut être poursuivie. Le jeton d’actualisation peut être utilisé pour obtenir un nouveau jeton d’actualisation. Le nouveau jeton d’actualisation peut être utilisé pour obtenir un autre jeton d’actualisation, etc. Il crée une chaîne. Cette propriété spécifie la longueur maximale de la chaîne de jetons d’actualisation. La valeur minimale est de 24h, la valeur maximale est de 365 jours.
allow_infinite_rolling_refresh_token : une fois que cette propriété est définie sur true, la chaîne de jetons d’actualisation n’est pas limitée dans le temps.

Ces propriétés peuvent être configurées à la fois pour les flux d’utilisateurs et les stratégies personnalisées (Identity Experience Framework).

User Flows

User Flows permet de configurer les propriétés du jeton d’actualisation sous Paramètres/Durée de vie du jeton

Stratégies personnalisées

Les stratégies personnalisées tirent parti de l’extension d’OpenId Connect TechnicalProfile . Le pack de démarrage des stratégies personnalisées Azure AD B2C implémente la stratégie personnalisée TrustFrameworkBase, qui définit JwtIssuer - OpenId Connect TechnicalProfile . Il peut être hérité et étendu avec les paramètres de jeton d’actualisation comme ci-dessous

La configuration de la durée de vie du jeton d’actualisation est reflétée dans la réponse du point de terminaison /token. La réponse inclut refresh_token_expires_in propriété qui correspond à refresh_token_lifetime_secs paramètre. Grâce à cette application, vous pouvez Demandez un nouveau jeton d’actualisation avant l’expiration du jeton actuel.

La révocation du jeton d’actualisation

Azure AD B2C ne fournit pas le point de terminaison OAuth /revocation qui est normalement utilisé pour informer le serveur d’authentification que le jeton spécifique ne doit plus être accepté.

La révocation du jeton peut être réalisée de trois manières différentes en utilisant

1. Utilisation de Powershell

2. Utilisation de l’API Graph

3. À l’aide du portail Azure,

le bouton Révoquer la session est disponible dans les paramètres utilisateur du locataire B2C

Cette solution n’invalide pas directement le jeton d’actualisation. Il est conçu pour révoquer la session de l’utilisateur, et non pour actualiser les jetons. Bien qu’il soit possible d’implémenter une logique personnalisée qui arrête l’utilisation du jeton d’actualisation, une fois la session utilisateur révoquée. L’implémentation spécifique est décrite dans la section Personnalisation du flux de jeton d’actualisation.

Scénarios de révocation Azure AD B2C

Les

possibilités de révocation de jeton Azure AD B2C semblent être conçues pour les scénarios d’utilisation par l’administrateur. Par exemple, lorsque l’utilisateur perd un appareil, l’administrateur peut révoquer les jetons, de sorte qu’une réauthentification sera requise.

Cette approche ne fonctionne pas bien avec les scénarios où les utilisateurs doivent révoquer leurs propres jetons. Cependant, il s’agit d’une exigence valable pour des raisons de sécurité. Une fois que l’utilisateur se déconnecte de l’application, les jetons d’actualisation sont généralement supprimés de la mémoire de l’application, mais ils ne sont pas invalidés sur le serveur d’authentification et peuvent toujours être utilisés. Cela crée un risque d’utilisation malveillante des jetons d’actualisation interceptés.

Révocation et jetons d’accès La

révocation du jeton d’actualisation n’invalide pas le jeton d’accès. L’utilisateur ne perd pas l’accès immédiatement. Les jetons d’accès sont valides jusqu’à leur expiration. Une fois que l’application obtient un jeton d’accès, il n’y a aucun moyen de l’empêcher d’accéder à la ressource avec ce jeton d’accès. La révocation du jeton d’actualisation empêche l’acquisition de nouveaux jetons d’identification/d’accès sans réauthentification.

Restant

dans le contexte de la sécurité, il est recommandé aux serveurs d’authentification de générer des jetons d’actualisation à usage unique. Le jeton d’actualisation ne doit être utilisé qu’une seule fois pour demander de nouveaux jetons d’accès et d’actualisation. Le nouveau jeton d’actualisation ne peut être utilisé qu’une seule fois. Cette approche atténue le risque d’utilisation du jeton d’actualisation, même s’il est intercepté par l’attaquant. Bien qu’Azure AD B2C permette par défaut d’utiliser le même jeton d’actualisation plusieurs fois.

Personnalisation du flux de jeton d’actualisation

La personnalisation des revendications de jeton peut être implémentée à l’aide de stratégies personnalisées Azure AD B2C. Le processus de génération des revendications peut être personnalisé, lorsque les jetons sont demandés spécifiquement à l’aide du jeton d’actualisation.

Cette fonctionnalité offre une variété de possibilités, par exemple

actualiser les revendications de l’utilisateur dans le jeton d’identification renvoyé. Certaines revendications peuvent avoir été modifiées après avoir été initialement générées lors du processus de connexion.
Appelez l’API externe pour vérifier si l’utilisateur, qui essaie d’actualiser le jeton, figure sur une liste noire. Interrompre la génération de jetons si c’est le cas.
Vérifiez si le jeton d’actualisation de l’utilisateur a été révoqué.

L’exemple ci-dessous explique comment vérifier si la session utilisateur a été révoquée avant d’actualiser le jeton.

Une fois que le point de terminaison /token est demandé avec grant_type=refresh_token , Azure AD B2C déclenche UserJourney , référencé dans RelyingParty en tant que point de terminaison avec Id=Token .

Le parcours RedeemRefreshToken est implémenté dans le pack de démarrage Azure AD B2C dans TrustFrameworkBase.xml fichier de stratégie. (Le pack de démarrage est Bien entendu, vous pouvez étendre, personnaliser ou utiliser différents UserJourney à la place.

RedeemRefreshToken UserJourney comprend trois étapes,

qui utilisent les TechnicalProfiles suivants

: RefreshTokenReadAndSetup : il renvoie simplement les paramètres de jeton d’actualisation tels que objectId et refreshTokenIssuedOnDateTime dans les revendications de sortie. Avant d’exécuter le jeton d’actualisation UserJourney, les revendications du jeton d’actualisation semblent déjà être préchargées dans le sac de revendications. (Il s’agit d’une approche différente de celle de l’implémentation de UserInfoEndpoint, où le profil technique dédié charge explicitement les revendications de jeton d’accès dans le sac de revendications).
AAD-UserReadUsingObjectId-CheckRefreshTokenDate – récupère l’utilisateur informations stockées dans Azure AD. Étant donné qu’il utilise AAD-UserReadUsingObjectId TechnicalProfile de base, les données utilisateur de base seront mises à jour dans id/access token retourné. De plus, la propriété refreshTokensValidFromDateTime est lue à partir d’AD. Lorsque le jeton d’actualisation de l’utilisateur est révoqué, refreshTokensValidFromDateTime est défini sur l’heure à laquelle cela s’est produit.

En comparant la propriété refreshTokensValidFromDateTime avec refreshTokenIssuedOnDateTime, il est possible de vérifier si le jeton d’actualisation utilisé doit être accepté par le serveur d’authentification. Cette logique est implémentée par la transformation de la revendication de sortie. Une fois que refreshTokensValidFromDateTime est supérieur à refreshTokenIssuedOnDateTime , l’exception est levée et UserJourney est interrompu. Dans ce cas, le serveur Auth renvoie la réponse http de la requête 400-Bad, y compris le corps :
JwtIssuer : profil technique OpenIdConnect qui émet le jeton demandé et le renvoie à la partie relais. Les propriétés du jeton d’actualisation décrites ci-dessus, dans la section Propriétés des jetons d’actualisation dans Azure AD B2C, peuvent être spécifiées dans sa définition.