Quelle est l'intention de L'expiration du jeton D'identification dans OpenID Connect?

Dans OpenID Connect un jeton d'accès a une heure d'expiration. Pour le flux de code d'autorisation, il 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 ID a également une heure d'expiration. Ma question Est Quelle est l'intention de cela?

Tout temps 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.

Tout comme vous vouliez:

  • donnez à votre jeton D'identification une expiration plus longue que l'expiration du jeton d'actualisation, ou
  • définissez-le à la même expiration que le jeton d'accès et prenez des mesures (quoi?) quand il expire, ou
  • consommez simplement le jeton D'identification dans votre client à la réception, puis ignorez l'heure d'expiration après cela?

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

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

Qui supporte (éventuellement) la troisième option surtout.

Modifier

Comme OpenID Connect construit sur OAuth2 la réponse à la question supplémentaire ci-dessous peut être trouvée dans la spécification OAuth2 {[25] } 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" expires_in " se rapporte-t-il dans ce cas? Le jeton d'accès, le jeton d'actualisation ou L'ID jeton?

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

62
demandé sur Appetere 2014-09-05 16:57:16

7 réponses

Je réponds à ma propre question car j'ai découvert que certaines des hypothèses derrière ma question étaient fausses, donc plus facile à 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 ClaimsIdentity, et le persistera, par exemple en utilisant un cookie.

Le jeton D'identification doit être non expiré à ce point d'utilisation (ce qui doit l'être, puisqu'il vient d'être publié). 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, à son tour, peut choisir sa propre stratégie pour la durée de la session avant que l'utilisateur ne se connecte à nouveau.

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

  • Les jetons D'identification sont uniquement destinés à s'authentifier auprès d'un Client (comme décrit ci-dessus).
  • Les jetons D'accès n'ont rien à voir avec les Clients. Ils sont pour l'accès aux ressources et un Client ne les gère que s'il a à son tour besoin d'appeler une ressource.
  • quelque chose comme une application autonome MVC ou WebForms seulement a besoin d'un jeton D'identification. S'il n'appelle pas une ressource externe, il n'y a rien à accorder l'accès, donc pas de jeton d'accès.
60
répondu Appetere 2014-09-12 14:14:15

J'ai dû creuser dans ce pour mes propres raisons et l'a écrit, donc je vais poster ce que j'ai appris ici...

Tout d'abord, je vais répondre à la question au risque d'indiquer 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 du questionneur indique qu'après l'authentification initiale de l'utilisateur, le jeton D'identification n'est plus utilisé. Cependant, puisque le jeton D'identification est signé par le fournisseur d'identité, il certainement pourrait être utile à tout moment pour 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 ID utilisateur ou d'une adresse e-mail n'est pas fiable car elle peut être facilement usurpée (n'importe qui peut envoyer une adresse e-mail ou un ID utilisateur), mais comme un jeton ID OIDC est signé par le serveur D'autorisation (qui a également l'avantage d'être un tiers), elle ne mécanisme.

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

Par conséquent, tout comme le jeton d'accès (utilisé pour l'autorisation - spécifiant quelles autorisations l'Utilisateur a) peut être actualisé, pouvez-vous actualiser le jeton D'identification (utilisé pour l'authentification-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 vais sauter ci-dessous parce que c'est une variante des deux autres).

Pour le flux implicite dans OIDC / OAuth , vous demandez le jeton ID au point de terminaison d'autorisation en redirigeant l'utilisateur dans le navigateur vers le point de terminaison D'autorisation et y compris id_token comme valeur du paramètre de requête response_type. Une réponse D'authentificationà flux implicite est requise pour inclure le id_token.

Pour le flux de Code D'authentification , le client spécifie code comme valeur du paramètre de requête response_type 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 de terminaison de jeton avec le code d'autorisation et, selon OIDC Core section 3.1.3.3 réponse de jeton réussie 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 ID, mais comment l'actualisez-vous? OIDC Section 12: utilisation des jetons D'actualisation a la déclaration suivante sur 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 du jeton de la Section 3.1.3.3 sauf cela Il peut ne pas contenir un id_token .

Il se peut que ne contienne pas de jeton ID et comme il n'y a aucun moyen spécifié de le forcer à inclure le jeton ID, vous devez supposer que la réponse ne contiendra pas le jeton ID. Donc, techniquement, il n'y a pas de moyen spécifié pour "actualiser" un jeton D'identification en utilisant un jeton d'actualisation. Par conséquent, la seule façon 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 démarrage du flux implicite ou du flux de code d'authentification comme décrit ci-dessus. La spécification OIDC ajoute un paramètre prompt request à 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.

26
répondu Scott Willeke 2016-02-11 06:56:33

C'est la même intention: vous ne pouvez pas utiliser le id_token après son expiration. La principale différence est qu'un id_token est 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 access_token régulier est généralement un artefact opaque (comme un GUID).

Le consommateur du {[0] } doit toujours en vérifier la validité (temporelle).

Je ne suis pas 100% familier avec IS, mais je suppose que c'est un champ de commodité. Vous devriez toujours vérifier le exp réclamation.

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

4
répondu Eugenio Pace 2014-09-06 00:55:54

L'actualisation d'un jeton signifie que vous pouvez l'utiliser à nouveau pour demander quelque chose au serveur d'autorisation (dans ce cas, le fournisseur Op - OpenID-Connect) même lorsque L'utilisateur N'est pas connecté. Généralement, vous permettre ceci pour des ressources limitées, et seulement après que l'utilisateur s'est connecté et authentifié au moins une fois. Les jetons d'actualisation eux-mêmes devraient également être limités dans le temps.

Dans OIDC flux implicite vous appelez le point de terminaison D'autorisation,
et recevez le jeton D'identification dans la réponse avec toutes les étendues et en eux toutes les informations de revendications.
Les appels suivants à une API sont destinés à être fait avec flux de code.
Le flux implicite est destiné à activer une application javascript uniquement ou un 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'id. Vous devriez forcer une nouvelle connexion pour cela.

Dans flux de code vous appelez l'OP de l'Autorisation d'extrémité, et de recevoir une code d'Autorisation (aussi appelé un jeton d'autorisation, ou authcode pour faire court). Cela devrait expirer similaire à id_token que vous avez reçu dans le flux implicite, pour les mêmes raisons et ne peut et ne doit pas être renouvelé.

Votre interface utilisateur ou votre application appelle ensuite le point de terminaison de jeton de L'OP et reçoit (parfois après le consentement ultérieur de l'utilisateur via une interface utilisateur pour permettre l'utilisation de leurs 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 du serveur, sauf comme un indice lors de la déconnexion, lorsque son expiration n'est plus importante, et donc, pour les raisons ci-dessus devrait 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 seulement à L'API quelles revendications l'utilisateur A, et quelles ressources (par étendues et les revendications de chaque étendue) l'Utilisateur a accepté de vous donner. Comme expliqué ci-dessus, il s'agit d'autoriser l'accès même après que l'utilisateur ne soit plus connecté. Bien sûr, vous ne souhaitez jamais autoriser l'actualisation de id_token, car vous ne voulez pas autoriser l'usurpation d'identité sans vous connecter.

4
répondu pashute 2015-11-21 23:26:53

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

Vous utilisez également id_token comme id_token_hint lorsque vous tentez 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 cela importe vraiment si le id_token est expiré à ce stade puisque vous ne vous souciez que de déconnecter un utilisateur particulier.

3
répondu dgonee 2015-05-18 22:41:55

Si je comprends bien, selon CE et la spécification OpenID Connect Core 1.0, Le jeton D'identification lui-même peut être stocké dans les cookies comme un mécanisme pour persister les sessions, et envoyé avec chaque demande d'authentification au Client. Le Client peut ensuite vérifier le jeton D'identification localement ou via le point de terminaison verifier du fournisseur (si fourni, comme le fait Google). Si le jeton est expiré, il doit effectuer une autre demande d'authentification, sauf cette fois avec prompt=none dans le Le paramètre d'URL. Assurez-vous également d'envoyer le jeton ID expiré dans le paramètre id_token_hint, sinon le fournisseur peut renvoyer une erreur.

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

3
répondu Morrowless 2016-08-23 15:15:31

TLDR;

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

Plus De Détails

Quelle est l'intention de l'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 de flux implicite OpenID :

Si l'une des procédures de validation définies dans échec du document, toutes les opérations nécessitant les informations qui n'ont pas réussi à valider correctement doivent être annulées et les informations qui n'ont pas réussi à valider ne doivent pas être utilisées.

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

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

Donc, si notre application cliente va prendre des mesures en fonction du contenu du jeton ID, nous devons à nouveau valider le jeton ID.

3
répondu Shaun Luttin 2016-11-16 00:38:22