OAuthとは？役割、フロー、トークン、セキュリティの基本

Scrapeless Scraping APIは、x-api-tokenヘッダーにアカウントAPIキーを使用し、OAuthの委任された認可モデルとの具体的な対比を提供します。

OAuthとは？

OAuthは委任された認可のためのフレームワークです。アプリケーションが、リソースを所有するサービスのパスワードをユーザーに尋ねずに、保護されたリソースへの制限されたアクセスを要求できるようにします。ユーザーは認可サーバーと対話し、要求されたアクセスを承認し、クライアントはユーザーの主要な資格情報ではなくトークンを受け取ります。

RFC 6749はOAuth 2.0認可フレームワークを定義しています。それは役割、プロトコルエンドポイント、認可付与、アクセス・トークン、およびリフレッシュ・トークンについて説明しています。後の文書はフレームワークを更新し、現在の展開に対するセキュリティガイダンスを提供します。

OAuthはまた、自身の名義で行動するマシンクライアントを認可することもできます。クライアント資格付与は、確立されたサービス関係の下でリソースにアクセスするための秘密のクライアント向けに設計されています。このフローは、ユーザーがサードパーティアプリケーションを承認するのとは異なります。

OAuthの4つの役割

1つの組織は認可サーバーとリソースサーバーの両方を運営することができますが、それらは別々のプロトコル役割として残ります。役割を明確に保つことで、チームは検証とポリシーを正しい境界に配置できます。

認可コードフローの仕組み

1. クライアントは認可リクエストを作成します。 それはクライアント識別子、要求されたスコープ、リダイレクトURI、状態、PKCEチャレンジを持ってブラウザを認可エンドポイントに送信します。
2. 認可サーバーはユーザーの対話を処理します。 必要に応じてユーザーを認証し、要求されているアクセスを表示します。
3. リソース所有者はアクセスを承認または拒否します。 同意とポリシーは認可コードが発行されるかどうかを決定します。
4. ブラウザは登録されたリダイレクトURIに戻ります。 レスポンスには認可コードと状態の値が含まれます。
5. クライアントはレスポンスを検証します。 それは状態を、初期ブラウザセッションにバインドされた値と比較します。
6. クライアントはコードを交換します。 それはコードとPKCE検証子を使用してトークンエンドポイントを呼び出します; 機密クライアントは、承認された認証方法も使用します。
7. 認可サーバーはトークンを発行します。 応答には通常、アクセス トークンが含まれ、サーバーのポリシーに基づいてリフレッシュ トークンが含まれる場合があります。
8. クライアントはリソース サーバーを呼び出します。 リソース サーバーはトークンを検証し、スコープ、オーディエンス、およびリソース レベルのポリシーを強制します。

認可コードは中間的な資格情報であり、最終的な API トークンではありません。アクセス トークンをブラウザを通じて直接送信すると、フロント チャンネルの表面にさらされます。現在の慣行では、トークンエンドポイントでのアクセストークンの交換を維持し、適用可能な場合はPKCEとクライアント認証で保護します。

PKCEとは何ですか？

PKCEは、Code Exchange のためのProof Keyの略です。クライアントは、1回の認証試行のために高エントロピーの検証子を生成し、認証要求に派生したチャレンジを送信します。コード交換中、クライアントは検証子を提示します。認証サーバーはチャレンジを再計算し、値が一致したときのみコードを受け入れます。

RFC 7636はPKCEを定義しています。これは、パブリック クライアントのリダイレクトから盗まれた認可コードを保護するために作成され、現在のセキュリティ ガイダンスは、認可コード フローに広く適用されています。標準プロファイルによってサポートされている安全なチャレンジ メソッドを使用し、プレーンな検証子の変換を避けてください。

PKCEは状態を置き換えるものではありません。PKCEはコードの交換を開始しているクライアント インスタンスに結び付けます。状態は認可応答をブラウザのインタラクションに結び付け、クロスサイト リクエスト フォージェリやクライアントのセッション処理の混乱から保護を助けます。

アクセス トークンとリフレッシュ トークン

アクセス トークンはクライアントに付与された権限を表します。リソース サーバーは、リクエストが要求されたリソースおよび操作にアクセスできるかどうかを決定するためにそれを使用します。トークンは不透明で、イントロスペクションやサーバー側のルックアップが必要な場合もあれば、定義された署名トークン プロファイルに基づいて自己完結型の場合もあります。

リフレッシュ トークンを使用すると、クライアントは別のユーザー インタラクションなしで新しいアクセス トークンを要求できます。通常はリソース サーバーではなく、認可サーバーにのみ送信されます。リフレッシュ トークンは貴重な長期資格情報であり、保護されたストレージ、クライアント バインディング、サーバーによって定義された回転または再生コントロール、および取り消しサポートが必要です。

トークン形式はOAuthフローとは別です。OAuthは、JSON Web Tokensを必要としません。不透明なアクセス トークンは、中央のポリシーと取り消しが重要な場合に好ましい場合があります。自己完結型トークンはルックアップの必要性を減らすことができますが、発行者、オーディエンス、署名、時間の主張、およびプロファイルの許可されたアルゴリズムの注意深い検証が必要です。

スコープ、オーディエンス、同意

スコープは、権限またはアクセスカテゴリを表す認可サーバーによって定義された文字列です。クライアントはスコープを要求しますが、サーバーは同意とポリシーに基づいて権限を削減する場合があります。スコープ名は、内部エンドポイントをすべて反映するのではなく、有意義な機能を説明する必要があります。

オーディエンスは、目的のリソース サーバーまたはリソース セットを特定します。ある API 用に発行されたトークンは、有効な署名であるという理由だけで無関係な API に受け入れられてはなりません。リソース サーバーは、期待されるオーディエンスと発行者を検証する必要があります。

同意はポリシーの代替にはなりません。ユーザーは、持っていない権限を付与することはできません。認可サーバーとリソース サーバーは、引き続きテナント、ロール、所有権、リスク、およびリソース レベルの制限を強制します。

パブリックおよび機密クライアント

機密クライアントは、バックエンド サービスなど、そのオペレーターによって制御される環境を通じて資格情報を保護できます。パブリック クライアントは、ブラウザやユーザーに配布されるインストールされたアプリケーションなど、秘密を保持できない場所で実行されます。公共アプリケーションのすべてのコピーで同じクライアント シークレットを配布することは、それらのコピーを機密にすることにはなりません。

パブリック クライアントは、共有された埋め込みシークレットの代わりに、PKCE、正確なリダイレクト処理、プラットフォーム保護、および制限されたトークン権限に依存します。機密クライアントは、トークン エンドポイントで承認された認証方法を使用し、それらの資格情報をシークレット ライフサイクルを通じて保護する必要があります。

OAuthとAPIキー

APIキーは通常、クライアントまたはプロジェクトを直接識別します。これは、アカウント所有者が資格情報を供給する制御されたサーバー間関係に適しています。OAuthは、同意とスコープを含む補助の下でトークンを取得するためのプロトコルを追加します。

バックエンド サービスが自分のアカウントにアクセスし、プロバイダーのキー モデルが適切な制限を提供する場合は、API キーを使用します。サード パーティ クライアントがユーザーに代わって制約されたアクセスを必要とする場合、権限に独立した取り消しが必要な場合、またはエコシステムが標準化された認可フローを必要とする場合は、OAuthを使用します。

どちらのオプションも自動的に安全というわけではありません。APIキーは保護されたストレージと制限が必要です。OAuthは正しいエンドポイント検証、リダイレクト処理、トークン検証、スコープ設計、およびクライアントタイプの判断を必要とします。

OAuth対OpenID Connect

OAuthはリソースへのアクセスを認可します。それは、クライアントがユーザーのログイン ID として扱うことができる標準的な声明を定義していません。OpenID ConnectはOAuthの上に認証レイヤーを追加し、認証イベントと主体に関する署名付き主張であるIDトークンを導入します。

クライアントは、任意のOAuthアクセス トークンをログインの証明として扱うべきではありません。サインインの場合は、OpenID Connect フローを使用し、プロバイダー メタデータおよびプロファイルに従って ID トークンを検証します。発行者、オーディエンス、署名、時間の主張、使用時の nonce、認可応答のバインディングを含む。

現在のOAuthセキュリティガイダンス

RFC 9700はOAuth 2.0セキュリティの最新のベスト プラクティスを提供します。攻撃と実装経験に基づいてデプロイメントガイダンスを更新します。新しいシステムは、PKCEを使った認可コードフロー、正確なリダイレクトURIの一致、安全なブラウザの相互作用、保護されたトークン輸送を使用するべきです。

暗黙の付与は、認可応答を通じてアクセス・トークンを公開し、新しいクライアント向けには推奨される設計ではありません。リソースオーナーのパスワード資格情報付与は、クライアントにユーザーのパスワードを扱わせるもので、使用すべきではありません。これらの古いパターンはレガシーシステムに現れる可能性がありますが、新しい実装にコピーすることは強い境界を捨てることになります。

一般的なOAuthのミス

• OAuth認証の呼び出し。 OAuthはAPIアクセスを認可します; 標準的なログインIDレイヤーにはOpenID Connectを使用します。
• 緩いリダイレクトURIの一致。 プロファイルのルールの下で正確に登録されたリダイレクトURIのみを受け入れます。
• 状態検証のスキップ。 応答を開始ブラウザセッションに結びつけ、一致しないものは拒否します。
• PKCEの省略。 認可コードクライアントは、リクエストごとに新しい検証子と安全なチャレンジを使用する必要があります。
• 署名されたトークンの受け入れ。 リソースサーバーは、発行者、受信者、タイプまたはプロファイル、時間、署名、認可請求を検証しなければなりません。
• 過度のスコープ。 最小限の有用な権限を要求し、発行します。
• URLにトークンを置く。 HTTPS経由で認可ヘッダーを使用して、ログやブラウザの表面から漏えいを減少させます。

OAuthの使用例

実装チェックリスト

1. クライアントとユースケースのために付与を選択します。 インタラクティブなユーザー委任とサービスアクセスには異なる信頼境界があります。
2. 正確なリダイレクトURIを登録します。 環境を分け、オープンリダイレクタを避けます。
3. PKCEを使用した認可コードを使用します。 各認可リクエストに対して新しい検証子と状態値を生成します。
4. すべての応答を検証します。 状態、発行者のメタデータ（該当する場合）、コードバインディング、トークン応答フィールドをチェックします。
5. トークンを保護します。 URLやログから除外し、必要な最短期間保存し、安全なブラウザまたはサーバーのストレージパターンを使用します。
6. リソースサーバーで強制します。 トークンのプロファイル、発行者、受信者、有効期限、スコープ、リソースレベルのポリシーを検証します。
7. 撤回とインシデント対応を計画します。 ユーザーと管理者は、権限を削除し、侵害された資格情報を無効にする方法が必要です。

結論

OAuthは、ユーザーまたはサービスの主要な資格情報をAPIでクライアントが使用する限られたトークンから分離します。その役割、付与、スコープ、およびエンドポイントは標準的な認可境界を作りますが、プロトコルは依然として正確な実装に依存します。PKCEを使用した認可コード、正確なリダイレクト、狭く発行されたトークン、正しいリソースサーバーの検証、ログインにはOpenID Connectを使用することが、現在のシステムのための堅実な基盤を提供します。