JWT と OAuth: 究極の Web セキュリティにはどちらが適していますか

JWT と OAuth は両方とも、安全な認証と認可を提供することで、Web アプリケーションのセキュリティを強化するのに役立ちます。しかし、ユーザーが Web アプリケーションに安全にアクセスできるようにするには、どれを実装すべきでしょうか?この質問に答えるために、JWT と OAuth に関する詳細な記事を用意しました。

これを読むと、JWT と OAuth とは何か、それらが提供するメリット、違い、Web アプリケーションのセキュリティを強化するにはどちらを実装する必要があるかについて明確に理解できるようになります。

早速、早速見ていきましょう。

JWTとは何ですか?

JWT は JSON Web Token の略で、二者間で情報を JSON オブジェクトとして安全に共有する方法を定義するオープン スタンダードです。情報はデジタル署名されているため、関係者は JSON Web トークンを通じて送信された情報を信頼し、検証できます。

JWT のサイズが比較的小さいため、POST パラメーター、URL、または HTTP ヘッダー内を通じて送信できます。 JSON Web トークンには、ヘッダー、ペイロード、署名の 3 つの部分があります。

ヘッダーは、トークンの種類と使用されている署名アルゴリズムの種類を示します。 JWT のペイロード部分には、ユーザーおよび追加データに関するステートメントであるクレームが含まれています。

名前が示すように、JSON Web トークンの署名部分には、メッセージが途中で改ざんされていないことを検証する署名があります。

JWT の仕組み

JSON Web トークンがどのように機能するかを次に示します。

ユーザーのサインイン

ユーザーは、ユーザー名とパスワードを送信して Web アプリケーションにログインします。次に、アプリケーションはこれらのログイン資格情報を認証サーバーに転送します。

トークンの生成

認証サーバーはユーザーのログイン資格情報を検証した後、JSON Web トークンを生成し、ユーザーに送信します。これらの JWT には、ユーザーと認証セッションに関する重要な情報を含めることができます。ユーザーはこれらの JWT をローカルに保存します。設定に基づいて、サーバーはセキュリティを強化するために共有秘密キーまたは秘密キーを使用して JWT に署名することもできます。

トークンの検証

ユーザーがリソースにアクセスするためにアプリケーション サーバーにリクエストを行うとき、サーバー リクエストに JWT が含まれます。アプリケーション サーバーは、JWT 内の署名を検証し、ペイロード内のクレームをチェックして、要求されたリソースへのユーザーのアクセスが許可されているかどうかを確認します。

JWT が有効な場合、ユーザーは Web アプリケーション上の要求されたリソースへのアクセスを許可されます。

JWT の使用例

JSON Web トークンは次の方法で使用できます。

#1. 認可

ユーザーがログイン エンドポイント経由で Web アプリケーションに正常にログインすると、認証サーバーはユーザーに JWT を発行します。ユーザーは JWT を使用してアプリケーション内のリソースにアクセスしますが、これには自分の身元を証明するための認証が必要です。

関連記事: NodeJS で JWT を使用してユーザーを認証および認可する方法

当事者間の情報交換

JSON Web トークンは、有効なユーザーに情報を安全に送信するための適切なオプションとなります。 JSON Web トークンは、情報が元のソースからのものであることを保証するために署名されます。また、JWT (署名部分) の構造により、受信者は情報が途中で変更されていないことを検証できます。

JWT の利点

Web アプリケーションに JWT を実装する主な利点を次に示します。

• SAML トークンとは異なり、JWT は軽量です。そのため、HTML および HTTPP 環境に JWT を迅速に実装できるため、JWT はモバイル アプリケーションなどのクライアント アプリケーションに最適です。
• JWT は堅牢なセキュリティを提供します。 HMAC アルゴリズムを使用する共有シークレット、または非対称に署名する秘密キーを使用して、JWT に対称的に署名できます。
• JWT には有効期限メカニズムが組み込まれており、JWT の有効期限を設定してセキュリティを強化できます。
• JSON Web トークンは、さまざまなシングル サインオン ソリューションで広く採用されています。その結果、JWT での作業が容易になります。

さらに、JWT は社内のデータベース ストレージ スペースを節約できます。これは、サーバーでは JWT のみが作成され、JWT はクライアント側に保存されるためです。また、JWT はデータベース検索を必要としません。

そのため、JWT は迅速に検証でき、優れたユーザー エクスペリエンスを提供します。

JWT の制限

ただし、JWT はユーザーを認証する優れた方法です。これらには次のような特定の制限があります。

• 暗号化キーの安全性を確保するのはお客様の責任です。ハッカーが JWT に署名する鍵を手に入れたら、大きな問題に陥ります。ユーザーデータを改ざんする偽のトークンを作成する可能性があります。それはセキュリティ上の大きなリスクです。
• JWT ではチェックごとにデータベースを呼び出す必要がなく、これは良いことのように思えます。ただし、できるだけ早く取り消す必要がある場合は、それをブラックリストに登録する必要があります。それはすぐにできる簡単な作業ではありません。
• JWT の有効期限が切れたら、単にタイマーを延長するだけでは済みません。システムは、新しいトークンを取得するためにユーザーに再度ログインするように要求します。これによりプロセス全体が複雑になり、ユーザー エクスペリエンスとセキュリティ フローについてさらに考慮する必要があります。プロセスを容易にするために、JWT と組み合わせてリフレッシュ トークンを実装できます。アクセス トークンの有効期限が切れると、クライアントはログイン資格情報を再度送信することなく、これらの更新トークンを使用して新しいアクセス トークンをリクエストできます。
• Web アプリケーションに JWT を実装するのは簡単な作業ではありません。追加のエンジニアリング作業が必要になります。トークン作成プロセスを設定し、アプリケーションに適した適切な署名メカニズムを選択し、それをすべて既存のアーキテクチャと統合する必要があります。

JWT はワンステップのソリューションではなく、慎重な計画と実行が必要なプロジェクトです。

OAuthとは何ですか?

OAuth は Open Authorization の略で、認可のためのオープン標準の認可プロトコルです。これにより、ユーザーがサードパーティ アプリケーションのログイン資格情報を共有することなく、Web アプリケーションまたは Web サイトがユーザーに代わってサードパーティ アプリケーションによってホストされるリソースにアクセスできるようになります。

現在、OAuth 2.0 (OAuth の最新バージョン) として記述され、認証サーバーを介してユーザーを認証するために広く使用されています。

たとえば、OAuth を導入すると、ユーザーは Facebook または Google アカウントを使用してアプリケーションにサインインできます。ただし、ログイン資格情報を入力するのは Facebook または Google アカウントのみです。

OAuth の仕組み

たとえば、時間管理アプリがあるとします。また、誰でもアプリを効率的に使用できるようにするには、電子メールの受信トレイにアクセスする必要があります。以前は、アプリが受信トレイにアクセスできるようにするには、ユーザーはログイン資格情報をアプリと共有する必要がありました。 OAuth2.0はこの問題を解決しました。

OAuth2.0 ワークフローは次のようになります。

1. 時間管理アプリ (クライアント) は、保護されたリソースへのアクセスを要求します。この場合、それはユーザー (リソース所有者) が所有するユーザーの受信箱です。アプリは、ユーザーを承認されたエンドポイントに送信することでこれを行います。
2. リソース所有者 (ユーザー) は、時間管理アプリからのリソース アクセス要求を認証し、許可します。クライアント (アプリ) は、承認されたエンドポイントから承認付与を取得します。
3. アプリケーションは、ユーザーの受信トレイにアクセスするために、認可サーバーにアクセス トークンを要求します。これを行うには、認可付与を送信し、独自の ID 認証を使用します。
4. アプリの ID が認証され、認可付与が有効な場合、アプリはユーザーの受信トレイにアクセスするためのアクセス トークンを受け取ります。
5. アクセス トークンが有効な場合、アプリは認証のためにアクセス トークンを送信することでユーザー データ (ユーザーの受信トレイ) にアクセスできるようになります。

これで、時間管理アプリがユーザーの受信箱にアクセスできるようになりました。 Oauth には さまざまな許可タイプが あるため、許可フローは許可許可タイプに基づいて若干異なる場合があります。

OAuth の利点

OAuth を使用する主な利点は次のとおりです。

• OAuth は広く受け入れられている標準です。これは、すべての主要な認証サービスが OAuth を理解し、使用していることを意味します。
• OAuth は広く使用されており互換性があるため、ユーザーは多くの OAuth プラグインと機能から選択できるでしょう。
• OAuth は、ほぼすべてのプログラミング言語と Web フレームワークに対してテスト済みのクライアント ライブラリを提供します。したがって、OAuth では好みの言語を使用できます。
• OAuth は安全性が高く、十分に審査されています。非常に広く使用されているため、専門家はすでに考えられるすべてのセキュリティ リスクを検討しています。
• OAuth はコードの分離に最適です。認証タスクを処理するときに、メインのアプリケーション コードが混乱することはありません。これにより、長期的にはアプリの管理と更新が容易になります。

OAuthの使用例

以下に、OAuth の一般的な使用例をいくつか示します。

• OAuth 2.0 の最も一般的な用途は、サードパーティのアプリケーションを作成してユーザーのアカウントにアクセスすることです。 OAuth 2.0 を使用すると、ユーザーは、第三者にそれらのサービスのログイン資格情報を提供せずに、さまざまなサービスに保存されている自分のデータへのアクセスを第三者に許可できます。
• Web アプリケーション所有者は、OAuth 2.0 を使用してシングル サインオンを実装できます。プロジェクト用のこれらのオープンソース OAuth ソリューションを探索できます。
• API ゲートウェイに OAuth 2.0 を実装して、API ゲートウェイを認可サーバーとして機能させることができます。これにより、API ゲートウェイが有効なアクセス トークンを使用してクライアントからのリクエストを転送することが保証されます。
• OAuth 2.0 により、IoT や冷蔵庫やテレビなどのスマート デバイスがユーザーに代わってサードパーティ API と対話できるようになります。これは、ユーザーがスマート TV やゲーム コンソールなど、通常のキーボードを使用せずにガジェット上のアプリにログインする場合に便利です。

OAuthの制限事項

利用可能なフローの範囲は、OAuth を初めて使用する人にとっては困難になる可能性があります。単に 1 つを選ぶだけではありません。すべてのセキュリティ要件を満たすために、組み合わせが必要になる場合があります。この複雑さにより、初心者にとって、どこから始めればよいのか、何を使用すればよいのか、効果的に統合する方法を知ることが難しくなる場合があります。

各フローは、モバイル アプリ、サーバー間通信、Web アプリケーションなど、独自の目的を果たします。したがって、選択を行う前に、具体的なニーズを慎重に分析することが不可欠です。

OAuth 2.0 は安全性を保つために SSL/TLS に依存します。 SSL/TLS が正しく設定されていない場合、OAuth 2.0 のセキュリティが危険にさらされる可能性があります。

また、OAuth は、特にユーザーのアクティビティを追跡する場合に、プライバシーの問題を引き起こす可能性があります。 「Google でサインイン」などのサービスを使用すると、Google がそのサードパーティ サイトでのあなたのアクティビティを認識する可能性があります。 Google は、ユーザーがログインしていることを認識するだけでなく、ユーザーがそのサイトを操作する頻度と時間を追跡することもあります。

さらに、OAuth は、フロントエンドとバックエンドだけを持つアプリなど、より単純なセットアップでは過剰になる可能性があります。そのような場合には、その複雑さは必要ないかもしれません。

JWTとOAuthの違い

JWT と OAuth は、ユーザー ID を検証してリソースへのアクセスを承認するという重要な機能を果たします。これらはセキュリティ環境において不可欠なツールですが、範囲、複雑さ、用途が異なります。

特徴	JWT	OAuth
主な用途	JWT は主に API に焦点を当てています。	OAuth は、Web、ブラウザ、API、その他のアプリをカバーします。
トークンとプロトコル	JWT はトークン形式です。	OAuth は認証プロトコルです。
ストレージ	JWT はクライアント側のストレージのみに依存します。	OAuth はクライアント側とサーバー側の両方のストレージを使用します。
柔軟性	JWT の範囲はさらに限定されています。	OAuth は、より高い柔軟性と幅広いユースケースを提供します。
使いやすさ	JWT はよりシンプルで理解しやすいです。	OAuth はさらに複雑です。

JWT はより単純で API セキュリティに特化していますが、OAuth はさまざまなシナリオに適応できる包括的な認証メカニズム ソリューションを提供します。

また、OAuth を使用すると、ユーザーはログインの詳細を明らかにすることなく、サードパーティのアプリが別のプラットフォーム上の自分のデータにアクセスできるようになります。

どちらが優れているかは、問題のシステムまたはネットワークの特定のニーズによって異なります。

JWT と OAuth を併用できますか?

JWT と OAuth は異なる目的を果たしますが、組み合わせることもできます。

OAuth プロトコルでは、厳密に使用する必要があるトークン形式は指定されていません。したがって、OAuth で JWT を実装できます。

たとえば、OAuth2 認証サーバーは、JWT を特徴とするアクセス トークンを発行できます。また、この JWT にはペイロードに追加情報を含めることができ、パフォーマンスが向上します。これは、認証サーバーとリソース サーバー間の往復が減少するためです。

JWT と OAuth2 の組み合わせは、デュアル トークン アプローチを通じて行うこともできます。OAuth2 は、このメソッドで、access_token と JWT という 2 つの別個のトークンを発行します。 JWT には追加の ID 情報が含まれています。このアプローチにより、追加の詳細レイヤーが提供され、ユーザーのアクセスとデータをより詳細に制御できるようになります。

このデュアル トークン戦略を選択する場合は、OpenID Connect を使用することが重要です。 OpenID Connect は OAuth2 に基づいて構築されており、より標準化されたフィールドをトークンに追加します。

OAuth2 の代わりに JWT を使用すると、特定のタスクの処理が高速化され、複雑さが軽減されます。しかし、開発がより困難になる可能性もあります。

OAuth2 で JWT を使用することを決定する場合は、速度向上によって開発作業の追加が正当化されるかどうかを検討してください。

結論

究極の Web セキュリティをめぐる JWT と OAuth の戦いでは、それぞれに長所と短所があります。 JWT はステートレスで迅速な認証に優れていますが、取り消し機能が組み込まれていないなどの制限があります。 OAuth は複雑な認証シナリオには優れていますが、より単純なプロジェクトには過剰になる可能性があります。

堅牢な認可と効率的な認証が必要な場合は、OpenID Connect を介して JWT と OAuth を組み合わせることを検討してください。

選択は、これらのテクノロジーに関する誇大宣伝だけではなく、特定のプロジェクトのニーズに依存する必要があります。

さらに、これらの一般的なユーザー認証プラットフォームを調べて、アプリケーションに最適なソリューションを選択することができます。