OAuth vs JWT

JWTについて

サーバーで生成されるトークンであり、エンドユーザーに関する基本情報（主にメールID、ユーザーID、パスワード、ログイン情報など）を含みます。

名前の通り、トークンの情報はすべてJSON形式で保存されます。JWTの情報はクライアント側で扱いやすく、暗号技術も効果的に活用されています。

利点と欠点

JWTは、いくつかの明確なメリットがあるため、他の認証方法より選ばれることが多いです。

• JWTは自己完結しており、ユーザー情報の収集に手間がかからないため、各リクエストごとにデータベースの問い合わせやサーバー認証を行う必要がなく、大幅な時間と労力を節約できます。
• デジタル署名による安全性と信頼性が評価され、ハッカーや他のクライアントなど外部からの不正アクセスが困難です。
• JWTはデジタルストレージの使用量が少なく、サーバーで生成された後、クライアントに転送されて各リクエストに付与されます。
• 検証時にはデータベースの広範な検索が不要なため、扱いやすいです。

有望なメリットにもかかわらず、JWTにはいくつかの欠点も存在する点を見逃してはなりません。

• JWTの導入には、追加のエンジニアリング作業が必要です。
• 検証時にデータベースへの問い合わせを行わない仕組みは、即時の無効化にはブラックリストの実装が必要となり、手間がかかる点として問題視されます。 データベース
• 署名キーが攻撃されると大きなセキュリティ上の問題が発生し、ハッカーが特定目的のJWTを生成して実際のユーザーの識別を隠す可能性があります。
• トークンの有効期限が切れると再認証が必要となり、実装が複雑になります。

JWTの最適な活用例

JWTは、部分的な情報を未検証のクライアントへ伝達する環境や、ペイロードでクライアント側の情報検証が求められる場合に最も効果を発揮します。APIやサーバー間の認証が必要なケースに適した選択肢です。

JWTの安全な保存

JWTは機微なユーザー情報を含むため、その保存方法は十分に整え安全に行う必要があります。保管場所としてはエンドユーザーのブラウザ内の安全な場所、一般的にはhttpOnly cookieが推奨され、local storageやsession storageでの保存は避けるべきです。

API認証におけるJWT

サイバー世界におけるAPI利用の拡大とともに、その認証手法への関心も高まっています。JWTはこの用途において有効なツールであり、Googleも採用しているAPIアクセス制御機構は広く知られています。この仕組みについて理解することが重要です。

APIが設定されると、クライアントでトークンを生成できる秘密鍵が提供され、APIリクエスト時にこのトークンが付与されることで、特定のクライアントを識別するのに役立ちます。

JWTに関する十分な理解が得られたところで、次にOAuthの基本、各バージョン、進化の過程について説明します。

Open Authorization (OAuth) について

一度は耳にしたことがある有名なプロトコルです。安全なユーザー認証を実現するために用いられ、APIやサービスと混同されることはありません。OAuthは世界的に認知される標準規格で、HTTPS上で機能し、サーバー、API、デバイス、アクセストークンを利用するアプリと非常に相性がよいです。

OAuthを利用すると、アプリはクライアントアプリに対して安全かつ制御されたアクセス権を付与する方法を決定でき、Java、ウェブ、モバイル、ブラウザアプリの開発で広く利用されます。

OAuth 2.0

OAuth 2.0は、プロトコルとしてもフレームワークとしても機能する最新バージョンです。初期のOAuthの問題点を解消し、相互運用性を向上させたことで人気が急上昇し、TwitterやFacebookなどの有名なアプリで利用されています。

主な目的は、ユーザーデータやAPIなどの特定リソースへのアクセスを制御することです。

OAuthのグラントタイプ

グラントを提供するということは、ユーザーの要求に応じて特定または複数のリソースへのアクセスを許可することを意味します。OAuthは、ユーザーが情報へアクセス、制御、利用する権限を与える方法を5通り提供します。

以下に、ユーザーがトークンを取得（またはその取得を要求）する際の主要な5つのグラントタイプを示します。

• Authorization: 第三者リソースを使用して直接ログインでき、ユーザー名などの認証情報を入力する必要はありません。
• Implicit: コードの入力を求めず、ユーザーの同意後すぐにクライアントアプリへアクセストークンが付与されます。
• Resource owner credentials: リソースサーバーがトークンの有効性を確認し、有効であれば事前に定めた範囲に応じたユーザーデータを返します。
• Client credentials: ユーザーの文脈外でトークンを取得する際に用いられ、クライアントのみが使用します。
• Refresh token: アクセス中に新たなトークンが必要な場合に役立ちます。

トークン

OAuth（またはOAuth 2.0）はトークンがすべてです。そのため、トークンの意味を正しく理解することが重要です。OAuthでは2種類のトークンが存在します。

アクセストークンはクライアントからリクエストヘッダーまたはパラメーターとして送られ、第三者アプリがリソースサーバー上のユーザーデータへアクセスすることを許可します。トークンの有効期限機能により、クライアント側で第三者リソースの利用制限を設定でき、そのスコープの定義が重要です。

次にリフレッシュトークンがあります。これはアクセストークンと併せて発行されるものの、クライアントからのリクエストの一部ではなく、主に期限切れのトークンを更新する役割を担います。

メリット

このプロトコルは多くの理由で広く利用されています。その理由を知るため、以下のメリットを確認してください：

• 広く支持され、標準化された認証プロトコルであるため、多くの認証サービスと互換性があります。
• その普及と互換性により、豊富なOAuthプラグインや機能オプションが利用可能です。
• 複数の言語やフレームワークでのクライアントライブラリのテストが可能です。
• 認証コード処理中にアプリコードに影響を及ぼさないため、コードの疎結合に適しています。
• 入念なテストにより高いセキュリティが実現されています。

欠点

OAuthには欠点がないと期待されがちですが、実際にはいくつかの課題があります。以下に主要な課題を示します：

• 複雑なOAuthフローが複数存在するため、最適なものを選定するのは容易ではありません。
• ユーザーのプライバシー保護が十分ではありません。
• セッション管理の機能が不足しています。

JWT vs OAuth

• JWTは主にAPI向けに利用される一方、OAuthはウェブ、ブラウザ、API、その他多数のアプリやリソースで利用可能です。
• JWTはトークンの形式を定義し、OAuthは認証プロトコルを定義します。
• JWTはシンプルで学習が容易ですが、OAuthは複雑です。
• OAuthはクライアント側とサーバー側の両方でトークンを保存できますが、JWTはクライアント側のみで管理されます。
• JWTは利用範囲が限られているのに対し、OAuthは柔軟性が高く、幅広い用途に対応できます。

どちらもシステムやネットワークにアクセスする際のユーザーの信用性を確認するプロセスの一部です。両者を組み合わせて利用できるかについて、次に検証します。

別の記事比較もご覧ください - OAuthとSAML、OpenIDの違い

OAuthとJWTを組み合わせて利用可能か？

JWTとOAuthを詳しく検証すると、どちらか一方だけでは不十分な場合があることが理解できます。実際、両者を組み合わせることでより強固な認証が実現でき、互いに補完し合い安全なデータ伝送に寄与します。

両者が併用可能な主な理由は、事前に形式が定められていないため、OAuth2にJWTの導入の余地があるからです。

また、OAuth2認証サーバーがクライアントに返すaccess_tokenに、追加のペイロード情報を含むJWTが含まれる可能性もあります。

その場合、同じ情報の取得回数が減り、サーバーのパフォーマンス向上および長期的な運用コストの削減につながります。

さらに、OAuth2に2種類のトークンを発行させる方法もあります。最初のトークンはaccess_token、次に追加の識別情報を含むJWTトークンです。この方法を採用する際は、OpenID Connectを利用していることを確認してください。OpenID ConnectはOAuth2の拡張であり、さらなる標準化を提供します。

どのオプションが貴社のニーズに最適か

JWTとOAuthは、それぞれ独自のメリットを持つAPIの安全確保方法です。JWTは軽量で自己完結型のトークンが求められる、スケーラブルかつステートレスなシステム構築に適しており、一方OAuthは第三者サービスに対して制限付きでユーザーデータを提供するケースに向いています。

ただし、どちらか一方を選ぶ必要はなく、両技術を組み合わせることでそれぞれの強みを活かすことが可能です。その方法は以下の通りです：

• アクセス権の付与: クライアントがユーザーの保護された情報にアクセスする際、OAuthプロセスが起動し、認可プラットフォームを通じてユーザーが許可を与えます。
• トークンの生成: 認可が成功すると、プラットフォームはJWTのようなコンパクトな形式でトークンを生成し、ユーザーのアクセス権や識別情報を含みます。
• データ取得: クライアントはAPIリクエストのヘッダーにこのトークンを添付し、サーバーはその正当性を検証します。

OAuthとJWTの統合により、両技術の強みを活かした堅牢かつ効率的でスケーラブルなアクセス管理ソリューションが実現されます。

WallarmでAPIの保護を強化

強固な認証は重要ですが、それだけでは十分なセキュリティ対策とはなりません。貴社のAPI全体を守るためには、API保護とWebアプリのセキュリティを統合したプラットフォームが必要です。Wallarmはそのソリューションを提供します。デモを予約して、Wallarmが貴社のWebおよびAPI資産をいかに守るかを確認してみてください。