Google APIとOAuth2を使い始めたばかりです。クライアントが私のアプリを承認すると、「更新トークン」と有効期間の短い「アクセストークン」が与えられます。これで、アクセストークンの有効期限が切れるたびに、更新トークンをGoogleにPOSTして、新しいアクセストークンを取得することができます。
私の質問は、アクセストークンの有効期限が切れる目的は何ですか？更新トークンの代わりに、長持ちするアクセストークンが存在しないのはなぜですか？
また、更新トークンには有効期限がありますか？
参照アクセスGoogleのAPIへのOAuth 2.0を使用して GoogleののOAuth2のワークフロー詳細は。
回答:
これは実装に固有のものですが、一般的な考え方は、プロバイダーが短期のアクセストークンと長期のリフレッシュトークンを発行できるようにすることです。どうして？
いくつかのシナリオは、oauth2（またはその他の認証）システムを設計する際のアクセストークンと更新トークンの目的、およびエンジニアリングのトレードオフを説明するのに役立ちます。
Webアプリのシナリオでは、いくつかのオプションがあります。
誰かがなんとかセッションを乗っ取ったとしましょう。可能なことはページをリクエストすることだけです。
1と2の比較：
1では、access_tokenとrefresh_tokenは、認証サーバー（この場合はgoogle）とアプリサーバーの間のネットワーク経由でのみ移動します。これは安全なチャネルで行われます。ハッカーはセッションを乗っ取ることができますが、彼らはあなたのウェブアプリと対話することしかできません。2では、ハッカーはaccess_tokenを奪い、ユーザーがアクセスを許可したリソースへの独自のリクエストを作成できます。ハッカーがaccess_tokenを手に入れても、リソースにアクセスできる短いウィンドウしかありません。
どちらの方法でも、refresh_tokenとclientid / secretはサーバーにしか認識されないため、Webブラウザーから長期間のアクセスを取得することはできません。
oauth2を実装していて、アクセストークンに長いタイムアウトを設定しているとしましょう。
1）では、アプリサーバーで非表示になっているため、短いアクセストークンと長いアクセストークンの間に大きな違いはありません。2）では、誰かがブラウザでaccess_tokenを取得し、それを使用して長期間にわたってユーザーのリソースに直接アクセスできます。
モバイルでは、私が知っているいくつかのシナリオがあります。
clientid / secretをデバイスに保存し、デバイスのオーケストレーションがユーザーのリソースへのアクセス権を取得するようにします。
バックエンドアプリサーバーを使用してclientid / secretを保持し、オーケストレーションを実行します。一種のセッションキーとしてaccess_tokenを使用し、クライアントとアプリサーバーの間で渡します。
1と2の比較
1）デバイスにclientid / secretを設定すると、それらはもう秘密ではありません。もちろん、ユーザーの許可を得れば、誰でも逆コンパイルして、まるで自分のように振る舞うことができます。access_tokenとrefresh_tokenもメモリ内にあり、侵害されたデバイスからアクセスされる可能性があります。つまり、ユーザーが認証情報を提供しなくても、誰かがアプリとして動作する可能性があります。このシナリオでは、refresh_tokenはaccess_tokenと同じ場所にあるため、access_tokenの長さはハッカビリティに影響しません。2）では、clientid / secretも更新トークンも危険にさらされています。ここで、access_tokenの有効期限の長さは、ハッカーがユーザーのリソースを入手した場合に、ユーザーのリソースにアクセスできる時間を決定します。
ここでは、access_tokenの有効期限を、認証システムで保護している期間によって異なります。それがユーザーにとって特に価値のあるものである場合は、短くする必要があります。価値の低い何か、それは長くなることができます。
グーグルのような一部の人々は、refresh_tokenを期限切れにしません。Stackflowのようなものはそうします。有効期限の決定は、ユーザーの使いやすさとセキュリティの間のトレードオフです。更新トークンの長さは、ユーザーが返す長さに関連しています。つまり、更新をユーザーがアプリに戻る頻度に設定します。更新トークンが期限切れにならない場合、それらが取り消される唯一の方法は、明示的な取り消しによるものです。通常、ログオンは取り消されません。
長めのポストが役立つことを願っています。
他の応答に加えて：
取得すると、アクセストークンは通常、クライアントから保護されたリソースサーバーへのすべての要求と共に送信されます。これにより、アクセストークンの盗用と再生のリスクが生じます（もちろん、アクセストークンのタイプが「ベアラー」であると想定します（最初のRFC6750で定義されています）。
実際の生活におけるそれらのリスクの例：
リソースサーバーは通常、分散アプリケーションサーバーであり、通常、承認サーバーと比較してセキュリティレベルが低くなっています（SSL / TLS構成が低い、強化が少ないなど）。一方、承認サーバーは通常、重要なセキュリティインフラストラクチャと見なされ、より厳格なセキュリティ強化の対象となります。
アクセストークンは、リソースサーバーまたはクライアントで診断目的で合法的に収集されたHTTPトレース、ログなどに表示される場合があります。これらのトレースは、パブリックまたはセミパブリックの場所（バグトレーサー、サービスデスクなど）で交換できます。
バックエンドRSアプリケーションは、多かれ少なかれ信頼できるサードパーティにアウトソーシングできます。
一方、リフレッシュトークンは通常、ワイヤ経由で2回だけ送信され、常にクライアントと認証サーバーの間で送信されます。トークン）。これは、傍受とリプレイの大幅に制限された機会です。
最後に、リフレッシュトークンは、侵害されたクライアントに対する保護があっても、ほとんど提供しません。
これは本質的にセキュリティ対策です。アプリが侵害された場合、攻撃者は短期間のアクセストークンにのみアクセスでき、新しいトークンを生成する方法はありません。
更新トークンも有効期限が切れますが、アクセストークンよりもはるかに長く存続するはずです。