OpenID Connect (OIDC) プロトコルにおけるアクセストークン、リフレッシュトークン、ID トークンの理解

OIDC、OAuth 2.0、およびトークン#

OpenID Connect プロトコル、別名 OIDC は、アイデンティティ管理のための基礎的なフレームワークを提供するための広く採用された標準として登場しました。 これは、よく知られた OAuth 2.0 プロトコル 上に構築された認証レイヤーです。OAuth 2.0 が単にリソースの認可に関するものであるのに対し、OIDC はクライアント認証を標準化し強化するプロトコルであり、新たに導入された ID トークンが助けとなります。

待ってください... OAuth 時代にはアクセストークンやリフレッシュトークンを耳にしていたことがありますが、今度は OIDC で新しい概念が出てきましたか？これらのトークンの違いを本当に理解していますか？

OIDC のアクセストークン、リフレッシュトークン、ID トークンとは何か？#

実際のシナリオから始めましょう。

典型的なクライアントサーバーアプリケーションを開発していて、RESTful API を通じて相互通信していると想像してください。ほとんどの API をプライベートにして、認可されたクライアントのみがアクセスできるようにしたいと思っています。クライアントを認証し、サーバーへの API リクエストを認可するメカニズムが必要になります。

理想的には、あなたの RESTful API はステートレスであるべきで、サーバーはクライアントセッション情報を保存しないでください。有効なリクエストが入ってきたときに、サーバーはただリクエストされたデータを返すべきです。ここでトークンが活躍します。では、このような場合、どの種類のトークンを使用すべきでしょうか？

アクセストークンは API の保護に使用される#

OAuth 2.0 および OIDC では、各保護された API はリソースとして扱われます。アクセストークンは、クライアントが API リソースを要求するときにサーバーに送信するトークンであり、通常はリクエストヘッダーを介して送信され、JWT 形式で表されます。

サーバー側では、リクエストが届いた場合、サーバーは受信リクエストが有効なアクセストークンを持っているかどうかを確認するだけで済みます。認証プロセスには、通常、JWT トークンのデコード、署名と有効期限の確認、およびクライアントに必要な権限があることを確認するためのスコープクレームの検証が含まれます。

ただし、疑問に思うかもしれません：もしクライアントアプリケーションが成功したログインの後に有効なアクセストークンを持ち、アクセストークンを使用してサーバーAPIを要求できるのであれば、それだけで十分ではありませんか？なぜ他のトークンが必要なのでしょうか？

確かに、それは妥当な質問ですので、ステップバイステップで説明しましょう。

なぜリフレッシュトークンが必要なのか？#

技術的には、アクセストークンはシステムを動作させるための最低要件を満たしていますが、セキュリティ上の懸念から、アクセストークンの有効期間は非常に短い (通常は1時間) のが一般的です。したがって、もしアクセストークンだけであれば、エンドユーザーはアクセストークンが失効するたびに再認証しなければなりません。近代的なシングルページウェブアプリケーション (SPA) や特にモバイルアプリケーションにおいて、頻繁にログアウトされるのはかなり不便なユーザー体験です。私たちは単にユーザーのセキュリティを保護しようとしているのです。

したがって、トークンセキュリティとユーザーの利便性のバランスが必要です。それがリフレッシュトークンが導入された理由です。

リフレッシュトークンはなぜ長い寿命を持つことができるのか？#

アクセストークンは API リソースにアクセスするために使用されるため、その短命性は漏洩や侵害のリスクを軽減します。一方、リフレッシュトークンは新しいアクセストークンを交換するためにのみ使用されるため、アクセストークンと比べて使用頻度が低くなり、露出のリスクが軽減されます。したがって、リフレッシュトークンに長期間の有効性を持たせることが許容されます。

リフレッシュトークンのセキュリティを確保する#

リフレッシュトークンもクライアント側に保存されるため、特にシングルページアプリケーション (SPA) やモバイルアプリなどの公開クライアント向けに、非妥協を確保することは困難です。

Logto では、リフレッシュトークンにはデフォルトで自動回転メカニズム が有効にされており、次の条件を満たすと認可サーバーが新しいリフレッシュトークンを発行します：

• シングルページアプリケーション：送信元制約を受けないクライアントとして認識され、リフレッシュトークンの回転が義務付けられます。リフレッシュトークンの生存時間 (TTL) を指定することはできません。
• ネイティブアプリおよび従来のウェブアプリ：リフレッシュトークンの回転が自動的に有効になっており、TTL の 70% に達すると自動的に更新されます。詳細はこちら

管理コンソールのアプリケーション詳細ページでリフレッシュトークンの回転を無効にするオプションもありますが、この保護手段を維持することを強くお勧めします。

ID トークンとは何か、そしてなぜそれが重要なのか？#

ID トークンは、認証されたユーザーに関するアイデンティティ情報を提供する OIDC の特別な機能です。

アクセストークンが保護されたリソースにアクセスし、リフレッシュトークンが新しいアクセストークンを取得するために使用される一方で、ID トークンは通常、認可サーバーからのユーザーデータの追加リクエストを減らすためにクライアント側にユーザー情報をキャッシュするために使用されます。ほとんどの場合、ID トークンを持っていることはユーザーが認証されていることと同等であると言っても差し支えありません。

トークンの取り扱いに関するベストプラクティス#

• HTTPS を使用する：クライアントと認可サーバー間の通信を確保するために常に HTTPS を使用してください。これにより、不正な第三者がトークンを傍受し盗むのを防ぐことができます。
• 適切なトークンの有効期限を設定する：アクセストークンは露出のリスクを最小化するために短命であるべきです。リフレッシュトークンは長い有効期間を持つことができます。
• リフレッシュトークンの回転を有効にする：リフレッシュトークンの漏洩のリスクを軽減するためにリフレッシュトークンの回転を実装してください。
• 細かいアクセス制御を使用する：アクセス許可を制限するために細かいスコープを使用してください。クライアントアプリケーションに必要な権限のみをリクエストしてください。「全権」や「管理者」スコープを使用して、ほとんどの権限チェックをバイパスすることは絶対に必要でない限り避けてください。

OIDC におけるアクセストークン、リフレッシュトークン、および ID トークンの主要な違いを総括#

OIDC プロトコルにおいて、リフレッシュトークン、アクセストークン、および ID トークンは、ユーザー認証を安全かつシームレスに提供するために協働します。

• アクセストークンは保護されたリソースにアクセスするための認可を提供します。
• リフレッシュトークンは、新しいアクセストークンのためにユーザーの介入を排除します。
• ID トークンはクライアント上でキャッシュされたユーザー情報を提供し、パフォーマンスを向上させます。

これらのトークンの役割と重要性を理解することは、アプリケーションで OIDC 認証を実装する開発者にとって重要です。