V51: OAuth 2.0 プロトコル

この章では、すべての OAuth 実装者向けに RFC 6750 および 6749 から導き出された OAuth 2.0 の 現在のセキュリティのベストプラクティス を説明し、要約します。OAuth は API 保護の標準となり、OpenID Connect を使用したフェデレーションログインの基礎になりました。OpenID Connect 1.0 は OAuth 2.0 プロトコル上のシンプルな ID レイヤです。これによってクライアントは、認可サーバーによって実行される認証に基づいてエンドユーザの身元を検証したり、エンドユーザに関する基本的なプロフィール情報を相互運用可能な REST ライクな方法で取得できるようになります。

OAuth プロセスにはさまざまなペルソナが存在します。詳細については以下の用語セクションで説明します。あるペルソナの要件が他のペルソナに関連しない可能性があるため、この章の要件はそれらのペルソナに基づいて構成されています。

V51.1 認可サーバ

V51.2 OAuth クライアント

V51.3 リソースサーバ

用語

この章では OAuth 2.0 RFC 6749 で定義されている「アクセストークン」、「リフレッシュトークン」、「クライアント」、「認可サーバ」、「リソースオーナー」、「リソースサーバ」という用語を使用します。そのため、この章では以下の用語を定義します。

アクセストークン (Access tokens)

アクセストークンは抽象化を提供し、さまざまな認可構成要素 (ユーザ名とパスワード、アサーションなど) をリソースサーバが理解できる単一のトークンに置き換えます。この抽象化により、短期間有効なアクセストークンを発行可能になり、リソースサーバがさまざまな認証スキームを理解する必要がなくなります。

リフレッシュトークン (Refresh tokens)

リフレッシュトークンはアクセストークンを取得するために使用されるクレデンシャルです。これらは認可サーバによってクライアントに発行され、現在のアクセストークンが無効や期限切れになったときに新しいアクセストークンを取得したり、同一またはより狭い範囲の追加アクセストークンを取得するために使用されます (アクセストークンはリソースオーナーによって認可されるよりも短い有効期間と少ないパーミッションを持つことがあります)。

クライアント (Client)

クライアントは一般的にリソースオーナーの代わりに、その認可を得て、保護されたリソースリクエストを行うアプリケーションを指します。「クライアント」という用語は特定の実装特性 (たとえば、アプリケーションがサーバ、デスクトップ、またはその他のデバイス上で実行されるかどうか) を意味するものではありません。

認可サーバ (Authorization Server, AS)

認可サーバは、リソースオーナーの認証に成功し、認可を取得した後、クライアントにアクセストークンを発行するサーバまたはエンティティを指します。

リソースオーナー (Resource Owner, RO)

リソースオーナーは保護されたリソースへのアクセスを許可できるエンティティを指します。リソースオーナーが個人である場合、それはエンドユーザと呼ばれます。

リソースサーバ (Resource Server, RS)

リソースサーバは保護されたリソースをホストするサーバを指し、保護されたリソースへのアクセストークンを使用したリクエストを受け付けて応答できます。

OAuth 2.0 の基本

OpenID Connect フローでは、「nonce」パラメータにより CSRF 保護を提供します。さもなければ、ユーザエージェントに安全にバインドされ、「state」パラメータで届けられるワンタイムユーザ CSRF トークンを CSRF 保護に使用しなければなりません。

PKCE (Proof Key for Code Exchange Mechanism / Authorization Code Grant) - コード交換メカニズム/認可コード付与のための証明鍵

認可コード付与を利用する OAuth 2.0 パブリッククライアントは認可コード横取り攻撃の影響を受けやすくなります。Proof Key for Code Exchange (PKCE, 「ピクシー (pixy)」と発音) は認可コード横取り攻撃の脅威を軽減するために使用される技術です。

元来、PKCE はネイティブアプリのセキュリティ保護に特化して使用されることを意図していましたが、その後 OAuth 機能として導入されるようになりました。これは認可コードインジェクション攻撃から保護するだけでなく、パブリッククライアント用に作成された認可コードも保護します。PKCE により攻撃者は code_verifier の知識がなければ、認可サーバのトークンエンドポイントで盗まれた認可コードを引き換えることができなくなります。

PKCE チャレンジや OpenID Connect の「nonce」はトランザクション固有であり、トランザクションが開始されたクライアントとユーザエージェントに安全にバインドされなければなりません。

トークンリプレイの防止

トークンリプレイ攻撃を防ぐことは、OAuth 2.0 を使用および実装する上で非常に重要です。

アクセストークンの権限制限

トークンの権限を制限することで、クライアントに特定のリソースへの適切なアクセスが付与されます。

リソースオーナーのパスワードクレデンシャル付与

この付与タイプは認可サーバだけでなく、さまざまな場所でクレデンシャルを漏洩する可能性があります。リソースオーナーのパスワードクレデンシャル付与を二要素認証、暗号化クレデンシャル (WebCrypto, WebAuthn など) での認証、複数のステップを必要とする認証プロセスに適応することは困難または不可能になる可能性があります。

OAuth 2.0 参考情報

詳しくは以下の情報を参照してください。

PreviousV50: Web フロントエンドセキュリティNext付録 A: 用語集

Last updated