Dans OpenID Connect, un jeton d'accès a une heure d'expiration. Pour le flux de code d'autorisation, cela est généralement court (par exemple, 20 minutes), après quoi vous utilisez le jeton d'actualisation pour demander un nouveau jeton d'accès.

Le jeton d'identification a également une heure d'expiration. Ma question est quelle est l'intention de cela?

Tout délai d'expiration du jeton d'ID inférieur à l'heure d'expiration du jeton d'actualisation signifie que vous aurez éventuellement un jeton d'ID expiré, mais un jeton d'accès valide.

Alors êtes-vous censé:

• donner à votre jeton d'identité une expiration plus longue que l'expiration du jeton d'actualisation, ou
• définissez-le sur la même expiration que le jeton d'accès et prenez des mesures (quoi?) lorsqu'il expire, ou
• consommer simplement le jeton d'identification dans votre client à la réception, puis ignorer le délai d'expiration après cela?

La spécification OpenID Connect indique simplement que lors de la validation d'un jeton d'identification,

"The current time MUST be before the time represented by the exp Claim."

qui (éventuellement) prend en charge la troisième option ci-dessus.

ÉDITER

Comme OpenID Connect s'appuie sur OAuth2, la réponse à la question supplémentaire ci-dessous se trouve dans la spécification OAuth2 qui dit:

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

Une question connexe est lorsque vous échangez un code d'autorisation pour les jetons, la même spécification indique que vous pourriez obtenir une réponse telle que:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

Mais à quoi se rapporte "expires_in" dans ce cas? Le jeton d'accès, le jeton d'actualisation ou le jeton d'identification?

(Pour plus d'informations, IdentityServer3 définit cela sur l'heure d'expiration du jeton d'accès).

Je réponds à ma propre question car j'ai découvert que certaines des hypothèses derrière ma question étaient fausses, donc plus faciles à clarifier ici, plutôt que de réécrire la question.

Un jeton d'identification est destiné à prouver à un client que l'utilisateur s'est authentifié et qui il est en conséquence.

Lorsqu'un client reçoit un jeton d'identification, il fera généralement quelque chose comme le convertir en une ClaimsIdentity, et le conservera, par exemple en utilisant un cookie.

Le jeton d'identification doit être non expiré à ce stade d'utilisation (ce qu'il devrait être, car il vient d'être émis). Mais après cela, il n'est plus utilisé, donc peu importe s'il expire alors que l'utilisateur a toujours une session active. Le client dispose des informations d'authentification dont il a besoin et peut à son tour choisir sa propre politique pour la durée de la session avant que l'utilisateur ne doive se reconnecter.

Ma fausse hypothèse en posant la question était qu'un jeton d'identification et un jeton d'accès devaient être utilisés ensemble, et donc tous deux devaient avoir des dates d'expiration valides. Ceci est faux pour diverses raisons:

• Les jetons d'identification sont uniquement destinés à l'authentification auprès d'un client (comme décrit ci-dessus).
• Les jetons d'accès n'ont rien à voir avec les clients. Ils servent à accéder aux ressources et un client ne les gère que s'il a besoin à son tour d'appeler une ressource.
• Quelque chose comme une application MVC ou WebForms autonome n'a besoin que d'un jeton d'identification. S'il n'appelle pas de ressource externe, il n'y a rien à quoi accorder l'accès, donc pas de jeton d'accès.

J'ai dû creuser cela pour mes propres raisons et l'écrire, alors je posterai ce que j'ai appris ici ...

Tout d'abord, je répondrai à la question au risque de déclarer l'évidence: le jeton d'identification ne peut pas être approuvé et son contenu doit être ignoré si l'heure actuelle est supérieure à l'heure expirée. La réponse de l'interrogateur indique qu'après l'authentification initiale de l'utilisateur, le jeton d'identification n'est plus utilisé. Cependant, comme le jeton d'identification est signé par le fournisseur d'identité, il pourrait certainement être utile à tout moment de donner un moyen de déterminer de manière fiable qui est l'utilisateur à d'autres services qu'une application pourrait utiliser. L'utilisation d'un simple identifiant d'utilisateur ou d'une adresse e-mail n'est pas fiable car il peut être facilement usurpé (n'importe qui peut envoyer une adresse e-mail ou un identifiant d'utilisateur), mais comme un jeton d'identification OIDC est signé par le serveur d'autorisation (qui a également généralement l'avantage d'être un tiers), il ne peut pas être usurpé et est un mécanisme d'authentification beaucoup plus fiable.

Par exemple, une application mobile peut vouloir être en mesure d'indiquer à un service backend qui est l'utilisateur qui utilise l'application et il peut avoir besoin de le faire après la brève période suivant l'authentification initiale, moment auquel le jeton d'identification est expiré, et donc, ne peut pas être utilisé pour authentifier l'utilisateur de manière fiable.

Par conséquent, tout comme le jeton d'accès (utilisé pour l'autorisation - spécifiant les autorisations dont dispose l'utilisateur) peut être actualisé, pouvez-vous actualiser le jeton d'identification (utilisé pour l'authentification - en spécifiant qui est l'utilisateur)? Selon la spécification OIDC, la réponse n'est pas évidente. Dans OIDC / OAuth, il y a trois "flux" pour obtenir des jetons, le flux de code d'autorisation, le flux implicite et le flux hybride (que je sauterai ci-dessous car c'est une variante des deux autres).

Pour le flux implicite dans OIDC / OAuth, vous demandez le jeton d'identification au point de terminaison d'autorisation en redirigeant l'utilisateur dans le navigateur vers le point de terminaison d'autorisation et en l'incluant id_tokencomme valeur du response_typeparamètre de demande. Une réponse d'authentification réussie de flux implicite est REQUISE pour inclure le id_token.

Pour le flux de code d'authentification , le client spécifie codecomme valeur du response_typeparamètre de demande lors de la redirection de l'utilisateur vers le point de terminaison d'autorisation. Une réponse réussie comprend un code d'autorisation. Le client client fait une demande au point d'extrémité de jeton avec le code d'autorisation et, conformément à la section 3.1.3.3 du cœur d'OIDC, la réponse DOIT inclure un jeton d'identification .

Donc, pour l'un ou l'autre flux, c'est ainsi que vous obtenez initialement le jeton d'identification, mais comment l'actualiser? La section 12 de l'OIDC: Utilisation de jetons d'actualisation contient l'instruction suivante concernant la réponse du jeton d'actualisation:

Lors de la validation réussie du jeton d'actualisation, le corps de la réponse est la réponse de jeton de la section 3.1.3.3 sauf qu'il peut ne pas contenir un id_token .

Il peut ne pas contenir de jeton d'ID et comme il n'y a aucun moyen spécifié de le forcer à inclure le jeton d'ID, vous devez supposer que la réponse ne contiendra pas le jeton d'ID. Donc, techniquement, il n'y a pas de manière spécifiée pour «actualiser» un jeton d'identification à l'aide d'un jeton d'actualisation. Par conséquent, le seul moyen d'obtenir un nouveau jeton d'identification est de ré-autoriser / authentifier l'utilisateur en redirigeant l'utilisateur vers le point de terminaison d'autorisation et en démarrant le flux implicite ou le flux de code d'authentification comme décrit ci-dessus. La spécification OIDC ajoute un promptparamètre de demande à la demande d'autorisation afin que le client puisse demander que le serveur d'autorisation n'invite pas l'utilisateur avec une interface utilisateur, mais la redirection doit toujours se produire.

Si je comprends bien, conformément à cela et à la spécification OpenID Connect Core 1.0 , le jeton d'identification lui-même peut être stocké dans des cookies en tant que mécanisme pour conserver les sessions, et envoyé avec chaque demande nécessitant une authentification au client. Le client peut ensuite vérifier le jeton d'identification localement ou via le point de terminaison du vérificateur du fournisseur (s'il est fourni, comme le fait Google ). Si le jeton a expiré, il doit effectuer une autre demande d'authentification, sauf cette fois avec prompt=nonele paramètre URL. Assurez-vous également d'envoyer le jeton d'ID expiré dans le id_token_hintparamètre, sinon le fournisseur peut renvoyer une erreur.

Donc, il semble naturel que le jeton d'identification expire, mais prompt=nonegarantit que le nouveau jeton d'identification peut être obtenu en douceur sans intervention de l'utilisateur (à moins bien sûr que l'utilisateur ne soit déconnecté de cet OpenID).

C'est la même intention: vous ne pouvez pas utiliser le id_tokenaprès son expiration. La principale différence est que an id_tokenest une structure de données et que vous n'aurez pas besoin d'appeler de serveurs ou de points de terminaison, car les informations sont codées dans le jeton lui-même. Un régulier access_tokenest généralement un artefact opaque (comme un GUID).

Le consommateur du id_tokendoit toujours vérifier la validité (temporelle) de celui-ci.

Je ne connais pas à 100% le SI, mais je suppose que c'est un domaine de commodité. Vous devriez toujours vérifier la expréclamation.

L'expiration n'est qu'une des validations. id_tokenLes s sont également signés numériquement et c'est aussi une validation que vous devez effectuer.

Actualiser un jeton signifie que vous pouvez l'utiliser à nouveau pour demander quelque chose au serveur d'autorisation (dans ce cas l'OP - le fournisseur OpenID-Connect) MÊME LORSQUE L'UTILISATEUR N'EST PAS CONNECTÉ. Vous ne l'autorisez généralement que pour des ressources limitées, et uniquement après que l'utilisateur s'est connecté et a été authentifié au moins une fois. Les jetons d'actualisation eux-mêmes doivent également être limités dans le temps.

Dans le flux implicite OIDC, vous appelez le point de terminaison d'autorisation
et recevez le jeton d'ID dans la réponse avec toutes les étendues et dans celles-ci toutes les informations sur les revendications.
Les appels ultérieurs à une API sont censés être effectués avec un flux de code .
Le flux implicite est destiné à activer une application javascript ou navigateur uniquement. Pas une application qui interagit avec un serveur.
Donc, même s'il y avait un moyen de «rafraîchir» ce jeton, vous ne devriez pas - du point de vue de la sécurité - lui permettre de vivre trop longtemps. Il sera volé et réutilisé par des utilisateurs non autorisés se faisant passer pour l'identifiant. Vous devez forcer une nouvelle connexion pour cela.

Dans le flux de code, vous appelez le point de terminaison d'autorisation de l'OP et recevez un code d'autorisation (également appelé jeton d'autorisation, ou authcode en abrégé). Cela devrait expirer de la même manière que le jeton id_token que vous avez reçu dans un flux implicite, pour les mêmes raisons et ne peut et ne doit pas être renouvelé.

Votre interface utilisateur ou application appelle ensuite le point de terminaison Token de l'OP et reçoit (parfois après le consentement supplémentaire de l'utilisateur via une interface utilisateur pour permettre l'utilisation de ses ressources possédées sur le serveur de l'OP) à la fois:

• Un id_token, pour l'authentification - qui ne devrait plus jamais être utilisé dans les appels au serveur, sauf comme indice lors de la déconnexion, lorsque son expiration n'est plus importante, et donc, pour les raisons ci-dessus, doit être laissé expirer et ne jamais être actualisé.
• Un access_token - qui plus tard, lors de l'appel d'une API, peut être donné au point de terminaison UserInfo de l'OP. Cela renverra les revendications, et l'API peut autoriser en conséquence.

Vous pouvez actualiser ce access_token, car il indique uniquement à l'API les revendications de l'utilisateur et les ressources (par étendues et par revendications de portée) que l'utilisateur a accepté de vous donner. Comme expliqué ci-dessus, cela permet d'autoriser l'accès même après que l'utilisateur n'est plus connecté. Bien sûr, vous ne souhaitez jamais autoriser l'actualisation de id_token, car vous ne souhaitez pas autoriser l'emprunt d'identité sans vous connecter.

Je voulais publier cette réponse sous forme de commentaire, mais comme je n'ai pas été très actif sur StackOverflow, je suppose que je la poste comme réponse alternative.

Vous utilisez également id_tokencomme le id_token_hintlorsque vous essayez de déconnecter l'utilisateur d'une session http://openid.net/specs/openid-connect-session-1_0.html . Honnêtement, je ne pense pas que ce soit vraiment important si le id_tokenest expiré à ce stade, car vous ne vous souciez que de déconnecter un utilisateur particulier.

TLDR;

Validez le jeton d'identification avant de faire confiance à ce qu'il dit.

Plus de détails

Quelle est l'intention du délai d'expiration du jeton d'identification dans OpenID Connect?

L'intention est de permettre au client de valider le jeton ID, et le client doit valider le jeton ID avant les opérations qui utilisent les informations du jeton ID .

À partir de la spécification OpenID Implicit Flow :

Si l'une des procédures de validation définies dans ce document échoue, toute opération nécessitant les informations qui n'ont pas été validées correctement DOIT être abandonnée et les informations qui n'ont pas pu être validées NE DOIVENT PAS être utilisées.

Pour corroborer cela, la documentation OpenID Connect de Google dit ceci à propos de la validation du jeton d'identification:

Une chose qui rend les jetons d'identification utiles est le fait que vous pouvez les transmettre à différents composants de votre application. Ces composants peuvent utiliser un jeton d'ID comme mécanisme d'authentification léger authentifiant l'application et l'utilisateur. Mais avant de pouvoir utiliser les informations du jeton d'identification ou de vous y fier comme une affirmation que l'utilisateur s'est authentifié, vous devez le valider.

Ainsi, si notre application cliente entreprend une action en fonction du contenu du jeton d'identification, nous devons à nouveau valider le jeton d'identification.