OAuth はどのように機能するのか？

Scrapeless Agent Browser は、許可されたウェブサイトとの対話のためにクラウドブラウザーセッションを提供しますが、アプリケーション側は、その連携で使用される OAuth の権限とトークンに引き続き責任を負います。

OAuth はどのように機能するのか？

OAuth により、アプリケーションはリソース所有者のパスワードを取得することなく、認可サーバーを通じて保護されたリソースへの限定的なアクセスを得ることができます。アプリケーションは、承認された認可を表すアクセストークンを受け取り、そのトークンをリソースサーバーに提示します。リソースサーバーは、そのトークンが要求された操作を認可しているかどうかを判断します。

OAuth は認可フレームワークです。見慣れたサインインボタンには OAuth が関わっている場合がありますが、誰がサインインしたかを証明するには、ID プロトコルとその検証ルールが必要です。権限と ID を分離しておくことで、アプリケーションが任意のトークン交換の成功を、ユーザーの身元を示す十分な証拠として扱ってしまうことを防げます。

OAuth フローに参加するのは誰か？

OAuth フローには、リソースオーナー、クライアント、認可サーバー、およびリソースサーバーが関与します。リソースオーナーはアクセスを許可できます。クライアントは、そのアクセスを要求するアプリケーションです。認可サーバーはリクエストを評価し、トークンを発行します。リソースサーバーは保護されたデータや操作をホストします。

The OAuth 認可フレームワーク これらのロールを定義します。1 つの組織が両方のサーバーロールを運用することはできますが、責任は依然として異なります。認可サーバーでの認証が成功しても、リソースサーバーでのあらゆる操作が自動的に許可されるわけではありません。

スコープは、サービスの語彙の中で要求された権限に名前を付けるものです。カレンダー連携では、予定を変更するのではなく、読み取る権限のみを要求する場合があります。プロバイダーは、それらの名前が何を意味するのか、そしてユーザー、管理者、または別のポリシーのどれがそれらを承認しなければならないのかを定義します。クライアントは、その目的に実際に必要なアクセスのみを要求すべきです。

クライアントの種類は重要です。サーバーアプリケーションは、通常、制御されたバックエンド内で認証情報を保護できます。ブラウザやモバイルデバイスへ配布されるコードでは、埋め込まれたクライアントシークレットを機密情報として扱うことはできません。クライアント登録と選択するフローは、その境界を反映していなければなりません。

PKCE を用いた認可コードフローでは何が起こるのか？

認可コードフローは、ユーザーを認可サーバーへリダイレクトし、登録済みクライアントのリダイレクト先にコードを返し、そのコードをトークンと交換します。PKCE は、検証コードとそれから導出されるチャレンジを追加することで、認可リクエストと後続のトークン交換とを結び付けます。

1. クライアントは、検証子とそれから導出されたチャレンジを含む新しい認可トランザクションを作成し、レスポンスを検証するために必要な状態を記録します。
2. クライアントは、登録済みのクライアント識別子、リダイレクト先、要求された権限、およびチャレンジとともに、ブラウザーを認可サーバーへ送信します。
3. 認可サーバーは、必要に応じてユーザーを認証し、同意およびポリシーを評価します。
4. 認可サーバーは、クライアントに許可されたリダイレクト先の場所に認可コードを返します。
5. クライアントは、必要に応じて必須のクライアント認証を使用しながら、トークンエンドポイントで検証者と共にコードを送信して検証します。
6. クライアントは、付与範囲内で操作を行うために、アクセストークンを対象のリソースサーバーに提示します。

The PKCE チャレンジとベリファイアの仕組み サーバーがバインディングを正しく適用している場合、傍受されたコードの所持だけでは交換を完了するのに十分でないようにします。検証子はトランザクションに特有のものです。共有アプリケーション定数になってはなりません。

PKCE は他のあらゆる検証を任意にするものではありません。クライアントは依然として正しいサーバーを使用し、返されたレスポンスを検証し、トランザクション状態を保護し、リダイレクト規則を順守する必要があります。無関係なコード断片を寄せ集めてフローを組み立てるのではなく、プロバイダーに対応したメンテナンスされている OAuth 実装を使用してください。

アクセス・リフレッシュ・ID トークンとは何を意味するのか？

アクセストークンはリソースへのアクセスを許可し、リフレッシュトークンはサーバーポリシーに基づいて代替のアクセストークンを取得でき、IDトークンは OpenID Connect で認証情報を伝達します。これらのトークンは対象と検証要件が異なります。あるトークンを別のトークンの代わりに使用すると、認可エラーやセキュリティ上の欠陥を引き起こす可能性があります。

アクセス トークンは不透明な形式の場合もあれば、構造化された形式を使用する場合もあります。すべての OAuth トークンが JWT である、あるいはトークンをデコードできることがその有効性の証明になると仮定してはいけません。発行者、オーディエンス、有効期限、署名、またはサーバー側のトークン状態をどのように検証すべきかは、リソースサーバーの契約によって決まります。

リフレッシュトークンは任意です。その発行、有効な保存要件、ローテーションの挙動、および失効はプロバイダーごとに異なります。クライアントは、最初の認可が成功したからといって無期限のアクセスを想定すべきではありません。スコープの変更やアカウントポリシーによって、後続の操作で許可される内容が変わる可能性があります。

OpenID Connect のアイデンティティレイヤー OAuth の上に ID トークンと認証クレームを定義します。サインインを使用するクライアントは、そのプロトコルおよびプロバイダー構成に従って、ID 応答を検証しなければなりません。

クライアントはどの境界を保護しなければならないのか？

クライアントは、リダイレクト処理、トランザクションの関連付け、認証情報、およびあらゆるトークンの送信先を保護しなければなりません。OAuth 連携は、単なる HTTP リクエストの連鎖ではなく、一連の信頼に関する判断です。ある API 向けに発行されたトークンは、両者が Authorization ヘッダーを受け付けるからといって、無関係なサービスへ転送してはなりません。

The OAuth の最新ベストプラクティス は、フロー選択と攻撃対策に関する現時点でのセキュリティ基準を提供します。パブリッククライアントは PKCE を必ず使用する必要があり、機密クライアントでも PKCE の使用が推奨されます。リダイレクトの照合や、認可レスポンス注入への防御は、依然として設計の必須要素です。

サーバー側シークレットは、そのデプロイメントで承認されたシークレットストアに保存してください。リフレッシュトークンへのアクセスを制限し、トークン値を URL、ログ、分析情報、サポート用スクリーンショットなどに含めることは避けてください。認可コードも、利用可能な間は機密となり得るため、コールバックのロギングには慎重な設定が必要です。

ユーザーの認証情報を集める近道として、リソースオーナーパスワードクレデンシャルグラントを選択してはいけません。現在のセキュリティガイダンスでは、そのグラントは使用すべきでないとされています。ユーザーの同意や管理者ポリシーは、認可サーバーがサポートするユーザー体験を通じて扱うべきです。

OAuth はブラウザログインや API キーとどう違うのですか？

ブラウザのログインセッションは Web サイトの状態を維持し、API キーはサービスのキー運用ポリシーの下でのアクセス主体を識別し、OAuth は認可グラントを表します。これらの仕組みは 1 つのワークフロー内に同時に登場し得ますが、相互に代用はできません。Web サイトの Cookie が、そのまま委任された API 認証情報になるわけではありません。

Scrapeless Agent Browser は、あなたのアプリケーションに対して認可された操作を行うためのブラウザ環境を提供します。これは、ブラウザが訪問するすべての Web サイトに対する認可サーバーではありません。同意画面を開いたからといって、ユーザーの指示を超えて権限を承認することが自動化に許されるわけではありません。

The Scrapeless API キーの取り扱い要件 は、Scrapeless のサービス認証情報がどのように使用・保護されるかを説明します。OAuth ベアラー接頭辞を追加したり、Scrapeless キーを無関係なプロバイダから発行されたトークンとして扱ったりするのではなく、その文書化されたキーの契約に従ってください。

The バウンデッドコレクションワーカーのデプロイパターン は、シークレットを再利用可能なアプリケーションコードから分離する際に関係してきます。OAuth 連携も同様に、実行時の認証情報の扱い、アクセス制御、およびワーカーの目的とそれに与えられた権限との間に明確な境界を必要とします。

委任された連携はどのように設計されるべきですか？

委任された連携は、明確に定義されたユーザーアクションと、最小限で有用な権限セットから始まります。例として、ユーザーのカレンダーの空き状況を読み取るレポートアプリケーションを考えてみてください。アプリケーションは許可されたコールバックを登録し、プロバイダがサポートする認可フローを選択し、広範なアカウント管理ではなく空き状況に必要な権限を要求します。

コールバック後、バックエンドはトランザクションを検証し、許可された認証情報を安全に保存します。リソースリクエストは想定された API を対象とし、付与されたスコープの下で評価されます。アプリケーションは、ユーザー向けのログにトークンを露出させることなく、接続状態を記録します。

切断には明示的な設計が必要です。ローカルに保存された認証情報を削除し、適切な場合にはプロバイダがサポートする失効（revocation）機能を使用してください。アプリケーションの切断が、サーバー側の権限も取り消すのかどうかをユーザーに説明する必要があります。これらのアクションは関連していますが、常に同じ効果になるとは限りません。

拒否された同意、不一致のコールバック、有効期限切れのトランザクション状態、不十分なスコープを、成功パスと並行してテストしてください。制御されたプロバイダのテスト環境を使えば、例示的なシーケンスを実際の認可実行として扱うことなく挙動を検証できます。この概念的な例によって、本番アカウントの権限付与が行われていると主張するものではありません。

結論

OAuth を追跡するには、権限付与をたどってください：誰が承認したのか、どのクライアントが受け取ったのか、どのリソースがそれを受け付けるのか、そしてどれくらいの期間有効なのか。ブラウザセッションとサービスの API キーは分離しておきましょう。ブラウザベースのワークフローの場合は、対象プロバイダの権限や API ポリシーとは独立に Scrapeless の料金 を確認してください。