OAuth とは何か？委任されたアクセス、トークン、そして PKCE フロー

Scrapeless Agent Browser は、ブラウザーのナビゲーションとセッションベースのワークフローをサポートしますが、OAuth 権限は引き続きアプリケーションと認可サーバーの責任となります。

OAuth は委任された認可のためのフレームワークです

OAuth は、アプリケーションがリソース所有者のパスワードを収集することなく、保護されたリソースへの限定的なアクセスを取得できるようにする認可フレームワークです。たとえば、ユーザーはスケジューリングツールにカレンダーを読み取る権限を与えられますが、許可される操作はカレンダーサービス側で制御されます。スケジューリングツールは、ユーザーが再利用可能なパスワードを渡す代わりに、そのアクセスのための認証情報を受け取ります。

The OAuth 認可フレームワーク ロールと中核となるやり取りを定義します。リソースオーナーは関連するリソースを管理し、クライアントアプリケーションはアクセスを要求し、認可サーバーは自らのポリシーに基づいて認証情報を付与し、リソースサーバーは保護された API をホストします。1 つの組織が両方のサーバーロールを運用することもできますが、ロールを区別しておくことで、どこで認証、権限決定、およびトークン検証が行われるかを説明しやすくなります。

トークン付与は、アカウントを操作する包括的な許可よりも範囲が狭いものです。アクセスは、スコープ、対象リソース、期間、および認可サーバーのポリシーによって制約される場合があります。リソースサーバーは、その操作が許可されているかどうかを引き続き確認します。同意画面は要求されたアクセス内容を説明し、実際に付与されたクレデンシャルとサーバー側の制御によって、同意後にアプリケーションが実行できることが決まります。

認可と認証は異なる問いに答える

認可は、アプリケーションが行使できるアクセス内容を決定し、認証は特定のコンテキストにおけるアイデンティティを確立する。OAuth では、ユーザーが認可サーバーでサインインすることがあるが、そのやり取りによって、クライアント自身のログインシステムに適した標準化されたアイデンティティアサーションが自動的に与えられるわけではない。任意のアクセストークンをログインの証拠として扱うと、トークンの差し替え問題やオーディエンスに関する問題を引き起こす可能性がある。

The OpenID Connect アイデンティティレイヤー OAuth の上に認証を追加し、クライアントが検証するための ID トークンを定義します。アクセストークンはリソースサービス向けであり、ID トークンはクライアントの認証コンテキストを対象とします。この区別は標準仕様上も明確であり、アプリケーション設計においても明確であるべきです。無関係な API に ID トークンを送信しても、正しいアクセストークンを提示したことと同等にはなりません。

サインイン製品の場合、必要なアイデンティティプロトコルを明示的にサポートするプロバイダー統合を選択し、そのプロトコルを用いてトークンを検証してください。委譲された API アクセスでは、最小限で適切な権限のみを要求し、得られたアクセス認証情報は想定されたサービスのみに送信します。単一のユーザー向けボタンが両方のワークフローを隠している場合があるため、あらゆるソーシャルサインイン操作を単に OAuth ログインと呼ぶのではなく、実際の契約内容を確認してください。

認可コードは、ブラウザでの同意とトークンの利用を分離する

認可コードフローでは、ユーザーを認可サーバー経由でルーティングし、必要に応じてユーザーを認証し、アクセス要求を評価します。承認後、ブラウザは短命な認可コードを添えて、登録済みのクライアントリダイレクト先に戻ります。クライアントはその後、自身のクライアントタイプに適したパラメータと認証方式を用いて、そのコードをトークンエンドポイントで交換します。

コードは、カレンダーエントリやその他の保護されたレコードを読み取るために使用される API 資格情報ではありません。その目的は、フロントチャネルの認可インタラクションと、その後のトークンエクスチェンジを関連付けることです。リダイレクト URI の検証は厳格に行い、クライアントが開始したトランザクションにレスポンスを結び付けてください。想定していないオリジンで受信したコールバックや、期待されるトランザクションコンテキストを伴わないコールバックは、認証済みのアプリケーションセッションとして扱うべきではありません。

クライアント登録には、そのリダイレクト先や許可されたグラントなどの詳細が記述されます。資格情報を保護できるサーバーアプリケーションと、ブラウザに配信されるパブリックアプリケーションでは、持っている能力が異なります。サーバー側のクライアントシークレットをダウンロード可能な JavaScript にコピーしてはいけません。ダッシュボード上でどのようなラベルが付けられているかに関わらず、その値を秘密として保持できるかどうかは、アプリケーションの配布モデルによって決まります。

PKCE はコード交換を保護する

PKCE（Proof Key for Code Exchange）は、トランザクション固有のベリファイアを用いて、認可リクエストとトークンエクスチェンジを結び付けます。クライアントはベリファイアからチャレンジを導出し、そのチャレンジを認可リクエストに含めます。トークンエンドポイントでは、クライアントがベリファイアを送信し、サーバーはそのエクスチェンジが同じトランザクションから開始されたものであることを確認できます。

The PKCE メカニズム 認可コードの傍受への対処を行います。PKCE はパブリックアプリケーションを機密クライアントに変えるものではなく、ベリファイアは恒久的なクライアントパスワードではありません。特定のトランザクション内で生成して保持し、それを保護したうえで、認可リクエスト内でベリファイアを公開しないサポート対象のチャレンジ方式を使用してください。

The 現在のOAuthセキュリティのベストプラクティス パブリッククライアントの認可コードフローでは PKCE を必須とし、機密クライアントにも推奨しています。また、リダイレクトの完全一致、コードインジェクション、トークン漏えいにも対処しています。関連性の薄いスニペットを寄せ集めてフローを構成するのではなく、メンテナンスされている OAuth 実装を通じてこれらの要件を適用してください。正しいライブラリであっても、発行者 (issuer)、リダイレクト、リソースの設定が正しくなければなりません。

アクセス トークンとリフレッシュ トークンには別々のライフサイクルがある

アクセス トークンは、リソースサービスに必要な認可を保持または参照します。その形式は一般的な OAuth フレームワークによって固定されているわけではなく、サービスは不透明な値でも構造化トークンでも使用できます。クライアントは、すべてのアクセス トークンが可読な JSON Web Token であると仮定するのではなく、文書化されたレスポンスフィールドとリソース要件に依拠すべきです。

リフレッシュ トークンは、アクセス トークンを取得するために認可サーバーで使用される別の資格情報です。通常のリソース API には送信すべきではありません。サーバーがそれを発行するかどうか、有効期間、およびどのような保護が適用されるかは、クライアントとプロバイダーのポリシーに依存します。1 つのアクセス トークンより長いライフサイクルを持つ場合があるため、価値ある秘密として保護してください。

失効にも、ローカルの文字列を削除すればよいと暗黙にされるのではなく、定義されたインターフェースがあります。 OAuth トークン失効メカニズム は、クライアントが認可サーバーに対して、そのトークンがもはや不要になったことを通知できるようにします。ローカルのログアウト、付与の失効、すべてのアプリケーションセッションの終了は、異なる影響を持ち得ます。ユーザーが連携解除によって実際に何が変わるのかを理解できるよう、それらの影響を文書化してください。

スコープ、オーディエンス、およびサーバーポリシーがアクセスを制限する

スコープは、認可システムの語彙の中で、要求または付与された機能を表します。その名前と意味はプロバイダーに属します。読み取り指向のスコープであっても機微な記録を公開し得るため、プロダクト機能に必要なものだけを要求し、その理由を説明してください。将来の開発を容易にするという理由だけで、アプリケーションが広範な書き込み権限を要求すべきではありません。

想定されるリソースまたはオーディエンスも、別の境界です。あるサービス向けに発行されたトークンは、別のサービスで同等の認可として受け入れられるべきではありません。リソースサーバーは、選択したトークンメカニズムを使って、関連する発行者 (issuer)、オーディエンス、有効期限、および認可の詳細を検証しなければなりません。有効な署名だけでは、その資格情報が要求された操作に適切であることは保証されません。

クライアントクレデンシャルフローは、ユーザーの委任同意を表さないコンテキストにおけるアプリケーションアクセスに対応します。デバイス指向のフローは、他のインタラクション制約に対応します。すべてのプロダクトを 1 つの馴染みのあるフローに押し込むのではなく、実際のアプリケーションタイプでサポートされているグラントを選択してください。サービスのドキュメントに OAuth が記載されているからといって、すべてのグラント、スコープ、クライアントタイプがすべてのアカウントで利用可能であるとは限りません。

ブラウザ状態を OAuth 資格情報から分離して保つ

ブラウザクッキー、アプリケーションセッション、OAuth 資格情報は、ライフサイクルの異なる関連する実装上の関心事です。ブラウザは、API トークンの有効期限が切れてもサインインしたままでいられますし、特定のブラウザビューが閉じた後でも、アプリケーションが有効な委任トークンを保持している場合があります。ブラウザ状態を無関係なサービスへコピーするのではなく、関連する資格情報を保持しているコンポーネントで権限エラーを診断してください。

「 Scrapeless API キー取り扱い要件 は、Scrapeless プロダクトにアクセスするために使用される別の資格情報について説明します。Scrapeless API キーは、対象ウェブサイト向けの OAuth アクセストークンではありません。関連する API 認証方式 は資格情報スキームの区別に役立ち、 Scrapeless 料金 は、サードパーティの認可権ではなくサービス利用を対象とします。

委任された連携を拡張する前に見直す

委任された連携には、明確な権限の棚卸しが必要です。発行者、想定リソース、要求スコープ、クライアントタイプ、リダイレクト先、資格情報の保管場所、および連携解除時の挙動を記録してください。通常のアプリケーションテレメトリと、トークンを含むリクエストデータを分離し、日常的なログが制御不能な資格情報ストアにならないようにします。権限境界は、認可されたアカウントと文書化されたアクセスレベルを使ってテストしてください。

仮想的なカレンダー連携は、ユーザーが承認した 1 つの機能に対する読み取り専用アクセスから始めることができます。その受け入れ基準には、正しいアカウント、許可されたカレンダーリソース、動作する切断パス、そしてクライアントから見えるログにシークレットが含まれていないことを含めるべきです。具体的な機能で必要になったときにのみ権限を拡張してください。その規律により、同意リクエストの説明がしやすくなり、認証情報が漏えいした場合の影響も抑えられます。

結論

OAuth は、定義されたロール、認証情報、およびサーバーポリシーを通じて特定のアクセス権を委譲します。実際のクライアントタイプに合ったフローを選択し、必要に応じて PKCE を使用し、アイデンティティアサーションとリソースアクセス用トークンを分離してください。保守しやすい連携は、機密性の高いアカウントデータを扱う前に、スコープ、ストレージ境界、および切断時の挙動を明確にします。