OpenID Connectでは、アクセストークンには有効期限があります。認証コードフローの場合、これは通常短い（たとえば、20分）後、更新トークンを使用して新しいアクセストークンを要求します。

トークンIDもは有効期限の時間を持っています。私の質問は、これの意図は何ですか？

IDトークンの有効期限が更新トークンの有効期限よりも短い場合は、最終的にIDトークンの有効期限が切れますが、有効なアクセストークンがあることを意味します。

だからあなたはするつもりですか：

• IDトークンの有効期限を更新トークンの有効期限より長くするか、
• アクセストークンと同じ有効期限に設定し、有効期限が切れたときに何らかのアクション（何？）を実行するか、
• 受信時にクライアントでIDトークンを消費し、その後の有効期限を無視しますか？

OpenIDの接続仕様は、単に、IDトークンを検証する際と言います

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

これは（おそらく）上記の3番目のオプションをサポートします。

編集

OpenID ConnectはOAuth2に基づいて構築されているため、以下の補足質問に対する回答は、OAuth2仕様に記載されています。

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

関連する質問は、トークンの認証コードを交換するときに、同じ仕様で次のような応答が返される可能性があることです。

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

しかし、この場合、「expires_in」は何に関連していますか？アクセストークン、更新トークン、またはIDトークン？

（詳細については、IdentityServer3はこれをアクセストークンの有効期限に設定します）。

私は自分の質問に答えています。私の質問の背後にあるいくつかの仮定が間違っていたので、質問を書き直すよりも、ここで明確にする方が簡単です。

IDトークンは、ユーザーが認証したこと、およびその結果としてユーザーが誰であるかをクライアントに証明するためのものです。

クライアントがIDトークンを受信すると、通常、それをClaimsIdentityに変換し、Cookieを使用するなどしてこれを永続化します。

IDトークンは、この使用時点で有効期限が切れていない必要があります（発行されたばかりなので、有効期限が切れていないはずです）。ただし、この後は再び使用されないため、ユーザーがまだアクティブなセッションを保持している間に期限切れになっても問題ありません。クライアントは必要な認証情報を持っており、ユーザーが再度ログインするまでのセッションの継続時間について独自のポリシーを選択できます。

質問をするときの私の間違った仮定は、IDトークンとアクセストークンを一緒に使用する必要があるため、両方に有効な有効期限が必要であるというものでした。これはさまざまな理由で間違っています。

• IDトークンは、クライアントへの認証専用です（上記のとおり）。
• アクセストークンはクライアントとは何の関係もありません。これらはリソースへのアクセス用であり、クライアントはリソースを呼び出す必要がある場合にのみそれらを処理します。
• スタンドアロンのMVCまたはWebFormsアプリケーションのようなものは、IDトークンのみを必要とします。外部リソースを呼び出していない場合は、アクセスを許可するものがないため、アクセストークンはありません。

私は自分の理由でこれを掘り下げて書いたので、ここで学んだことを投稿します...

まず、明らかなことを述べるリスクを冒して質問に答えます。IDトークンは信頼できず、現在の時刻が期限切れの時刻よりも大きい場合は、その内容を無視する必要があります。質問者の回答は、ユーザーの最初の認証後、IDトークンは再び使用されないと述べています。ただし、IDトークンはIDプロバイダーによって署名されているため、アプリが使用している可能性のある他のサービスに対してユーザーが誰であるかを確実に判断する方法を提供することは、いつでも役立つ可能性があります。単純なユーザーIDまたは電子メールアドレスの使用は信頼できません 簡単になりすますことができるため（誰でも電子メールアドレスまたはユーザーIDを送信できます）、OIDC IDトークンは認証サーバーによって署名されているため（通常はサードパーティであるという利点もあります）、なりすましはできず、はるかに信頼性の高い認証メカニズム。

たとえば、モバイルアプリは、バックエンドサービス伝えることができるようにしたいことがあり、ユーザーがそのアプリを使用しているし、それがIDトークンの有効期限が切れている、その時点で初期認証、次の短い期間の後にそうする必要があるかもしれないですがしたがって、ユーザーを確実に認証するために使用することはできません。

したがって、アクセストークン（認証に使用-ユーザーのアクセス許可を指定）を更新できるのと同じように、IDトークン（認証に使用-ユーザーを指定）を更新できますか？OIDC仕様によると、答えは明らかではありません。OIDC / OAuthには、トークンを取得するための3つの「フロー」があります。認証コードフロー、暗黙フロー、およびハイブリッドフローです（他の2つのバリアントであるため、以下ではスキップします）。

OIDC / OAuthの暗黙的なフローの場合、ブラウザのユーザーを承認エンドポイントにリダイレクトしid_token、response_typeリクエストパラメータの値として含めることで、承認エンドポイントでIDトークンをリクエストします。暗黙のフロー成功した認証応答を含めるために必要ですid_token。

以下のために認証コードの流れ、クライアント指定codeの値としてresponse_typeリクエストパラメータは、認可エンドポイントにユーザーをリダイレクトするとき。正常な応答には、認証コードが含まれます。クライアントクライアントは、認証コードを使用してトークンエンドポイントに要求を行い、OIDCコアセクション3.1.3.3の成功したトークン応答 に従って、応答にはIDトークンを含める必要があります。

したがって、どちらのフローでも、最初にIDトークンを取得する方法ですが、どのように更新しますか？OIDCセクション12：更新トークンの使用には、更新トークンの応答に関する次のステートメントがあります。

更新トークンの検証が成功すると、応答本文はセクション3.1.3.3のトークン応答になりますが、id_tokenが含まれていない場合があります。

IDトークンが含まれていない可能性があり、IDトークンを強制的に含める方法が指定されていないため、応答にIDトークンが含まれていないと想定する必要があります。したがって、技術的には、更新トークンを使用してIDトークンを「更新」する特定の方法はありません。したがって、新しいIDトークンを取得する唯一の方法は、ユーザーを認証エンドポイントにリダイレクトし、上記のように暗黙的なフローまたは認証コードフローを開始することにより、ユーザーを再認証/認証することです。OIDC仕様はprompt、承認要求に要求パラメーターを追加するため、クライアントは、承認サーバーがユーザーにUIを要求しないように要求できますが、リダイレクトは引き続き発生する必要があります。

私が正しく理解していれば、これとOpenID Connect Core 1.0の仕様によれば、IDトークン自体をセッションを永続化するメカニズムとしてCookieに保存し、認証が必要なすべてのリクエストとともにクライアントに送信できます。その後、クライアントはローカルで、またはプロバイダーの検証エンドポイントを介してIDトークンを検証できます（提供されている場合は、Googleのように）。トークンの有効期限が切れている場合はprompt=none、URLパラメータでの今回を除いて、別の認証リクエストを行う必要があります。また、id_token_hintパラメータで期限切れのIDトークンを送信してください。そうしないと、プロバイダーがエラーを返す可能性があります。

したがって、IDトークンの有効期限が切れるのは当然のように見えprompt=noneますが、ユーザーの介入なしに新しいIDトークンをスムーズに取得できるようにします（もちろん、ユーザーがそのOpenIDからログアウトしている場合を除く）。

それは同じ意図です：id_tokenそれが期限切れになった後は使用できません。主な違いは、anid_tokenはデータ構造であり、情報はトークン自体にエンコードされているため、サーバーやエンドポイントを呼び出す必要がないことです。レギュラーaccess_tokenは通常、不透明なアーティファクト（GUIDなど）です。

の消費者はid_token常にそれの（時間）有効性を検証しなければなりません。

私はISに100％精通しているわけではありませんが、便利な分野だと思います。常にexpクレームを確認する必要があります。

有効期限は検証の1つにすぎません。id_tokensもデジタル署名されており、これも実行する必要のある検証です。

トークンを更新すると、ユーザーがログインしていない場合でも、承認サーバー（この場合はOP-OpenID-Connectプロバイダー）から何かを要求するためにトークンを再度使用できるようになります。通常、これは限られたリソースに対してのみ許可し、ユーザーがログインして少なくとも1回認証された後にのみ許可します。更新トークン自体も時間制限する必要があります。

OIDCの暗黙的なフローでは、Authorizationエンドポイントを呼び出し、
すべてのスコープとそのすべてのクレーム情報とともに、応答でIDトークンを受け取ります。
その後のAPIの呼び出しは、コードフローを使用して実行することを目的としています。
暗黙的なフローは、JavaScriptのみまたはブラウザーのみのアプリを有効にすることを目的としています。サーバーと対話しているアプリではありません。
したがって、このトークンを「更新」する方法があったとしても、セキュリティの観点から、トークンの寿命を長くしすぎないようにする必要があります。IDを偽装した無許可のユーザーによって盗まれ、再利用されます。そのためには、新しいログインを強制する必要があります。

では、コードを流れるあなたはOPの認可エンドポイントを呼び出し、受信認証コードを（も許可トークンと呼ばれ、略してAUTHCODE）。これは、同じ理由で、暗黙のフローで受け取ったid_tokenと同様に期限切れになるはずであり、更新することはできません。

次に、UIまたはアプリはOPのトークンエンドポイントを呼び出し、（ユーザーがUIを介してさらに同意した後、OPのサーバーで所有されているリソースの使用を許可する場合があります）次の両方を受け取ります。

• 認証用のid_token-これは、ログアウト中のヒントとして、有効期限がもはや重要ではなくなった場合を除いて、サーバー呼び出しで二度と使用しないでください。したがって、上記の理由により、有効期限を切れさせ、更新しないでください。
• access_token-後でAPIを呼び出すときに、OPのUserInfoエンドポイントに与えることができます。これによりクレームが返され、APIはそれに応じて承認できます。

このaccess_tokenは、ユーザーが持っているクレームと、ユーザーが提供することに同意したリソース（スコープおよび各スコープのクレームによる）のみをAPIに通知するため、更新できます。上で説明したように、これは、ユーザーがログインしなくなった後でもアクセスを許可するためのものです。もちろん、ログインせずに偽装を許可したくないので、id_tokenの更新を許可したくはありません。

この回答をコメントとして投稿したかったのですが、StackOverflowにあまり積極的に取り組んでいないため、別の回答として投稿していると思います。

また、使用しid_tokenてid_token_hintセッションのうち、ユーザーがログインしようとしたときにhttp://openid.net/specs/openid-connect-session-1_0.html。正直なところid_token、特定のユーザーのログアウトのみを懸念しているため、この時点で有効期限が切れているかどうかはそれほど重要ではないと思います。

TLDR;

IDトークンの内容を信頼する前に、IDトークンを検証してください。

詳細

OpenID ConnectでのIDトークンの有効期限の意図は何ですか？

その目的は、クライアントがIDトークンを検証できるようにすることであり、クライアントはIDトークンの情報を使用する操作の前にIDトークンを検証する必要があります。

OpenIDの暗黙のフロースペック：

このドキュメントで定義されている検証手順のいずれかが失敗した場合、正しく検証できなかった情報を必要とする操作は中止する必要があり、検証に失敗した情報は使用しないでください。

これを裏付けるために、GoogleのOpenID Connectドキュメントには、IDトークンの検証について次のように記載されています。

IDトークンを便利にする1つの点は、アプリのさまざまなコンポーネントにIDトークンを渡すことができるという事実です。これらのコンポーネントは、アプリとユーザーを認証する軽量の認証メカニズムとしてIDトークンを使用できます。ただし、IDトークンの情報を使用したり、ユーザーが認証したことをアサーションとして信頼したりする前に、それを検証する必要があります。

したがって、クライアントアプリケーションがIDトークンの内容に基づいて何らかのアクションを実行する場合は、IDトークンを再度検証する必要があります。