リフレッシュトークンについて

最新の安全なアプリケーションでは、アクセストークンを使用してユーザーが適切なリソースにアクセスすることがよくありますが、これらのアクセストークンには通常、有効期間が限定されています。これは、さまざまなセキュリティ上の理由によるものです。たとえば、アクセストークンの有効期間を限定すると、攻撃者がトークンを盗んだ場合、それを使用できる時間が制限されます。さらに、アクセストークンに含まれている情報、またはアクセストークンによって参照される情報が古いものとなります。

アクセストークンが期限切れあるいは無効になっても、まだアプリケーションが保護されたリソースにアクセスする必要がある場合、アプリケーションは、再度許可を与えることをユーザーに強制することなく、新しいアクセストークンを取得する必要が生じます。この問題を解決するために、Auth0 2.0 ではリフレッシュトークンと呼ばれるアーティファクトを導入しました。リフレッシュトークンを使用すると、アプリケーションはユーザーに要求することなく、新しいアクセストークンを取得できます。

リフレッシュトークンは、アクセストークンを取得するプロセスの一部として、アプリケーションによって要求できます。多くの承認サーバーは、OpenID Connect 仕様で定義されているリフレッシュトークン要求メカニズムを実装しています。この場合、承認コードの要求を開始する際、アプリケーションに offline_access スコープを含める必要があります。ユーザーが正常に認証され、アプリケーションが保護されたリソースにアクセスすることにユーザーが同意した後、アプリケーションはトークンエンドポイントでアクセストークンとリフレッシュトークンの両方と交換できる、認証コードを受け取ります。

新しいアクセストークンが必要な場合、アプリケーションは付与タイプ refresh_token を使用して、トークンエンドポイントに POST 要求を返すことができます (Web アプリケーションには クライアントシークレットを含める必要があります)。リフレッシュトークンを使用して新しい IDトークンを取得するには、認可サーバーが OpenID Connectをサポートし、元のリクエストのスコープに openID が含まれていなければなりません。

多くの場合、リフレッシュ トークンは長期間有効ですが、認可サーバーはそれらを無効にすることができます。以下が、リフレッシュトークンが無効になる理由の例です。：

• 認証サーバーがリフレッシュトークンを取り消した。
• ユーザーが認証の同意を取り消した。
• リフレッシュトークンの有効期限が切れた。
• リソースの認証ポリシーが変更された (たとえば、元のリソースはユーザー名とパスワードのみを使用していたが、現在は MFA が必要)。

リフレッシュトークンは有効期間が長くなる可能性があるため、開発者は、トークンが漏洩しないように、厳密なストレージ要件が整っていることを確認する必要があります。たとえば、Webアプリケーションでは、リフレッシュトークンは認証サーバーに送信されるときにのみバックエンドを離れるべきであり、バックエンドは安全でなければなりません。クライアントシークレットも、同様の方法で保護する必要があります。モバイルアプリケーションはクライアントシークレットを必要としませんが、クライアントアプリケーションのみがアクセスできる場所にリフレッシュトークンを保存する必要があります。

Auth0を使用すると、認可コードフロー (通常のWeb またはネイティブ/モバイル アプリ用)、デバイスフロー、または リソース所有者のパスワード付与を使用するときに、リフレッシュトークンを取得できます。Auth0の主要なSDKはすべて、メッセージのフォーマットについて心配することなく、すぐに使用できるリフレッシュトークンの取得、使用、取り消しをサポートしています。SDKをサポートする言語には、Node.js、.NET、PHP、その他多数があります！

トークンを取り消す方法など、Auth0でのリフレッシュ トークンの詳細については、リフレッシュ トークンのガイドをご覧ください。