|
RFC 6819 |
| TOC |
|
本ドキュメントでは, OAuth 2.0仕様が定めるSecurity Considerationsの範囲を超え, OAuth 2.0プロトコルに関する包括的脅威モデルを基に, さらなるセキュリティ上の検討項目を示す.
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6819.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
|
RFC 6819 |
| TOC |
1.
Introduction
2.
Overview
2.1.
Scope
2.2.
Attack Assumptions
2.3.
Architectural Assumptions
2.3.1.
Authorization Servers
2.3.2.
Resource Server
2.3.3.
Client
3.
Security Features
3.1.
Tokens
3.1.1.
Scope
3.1.2.
Limited Access Token Lifetime
3.2.
Access Token
3.3.
Refresh Token
3.4.
Authorization "code"
3.5.
Redirect URI
3.6.
"state" Parameter
3.7.
Client Identifier
4.
Threat Model
4.1.
Clients
4.1.1.
Threat: Obtaining Client Secrets
4.1.2.
Threat: Obtaining Refresh Tokens
4.1.3.
Threat: Obtaining Access Tokens
4.1.4.
Threat: End-User Credentials Phished Using Compromised or Embedded Browser
4.1.5.
Threat: Open Redirectors on Client
4.2.
Authorization Endpoint
4.2.1.
Threat: Password Phishing by Counterfeit Authorization Server
4.2.2.
Threat: User Unintentionally Grants Too Much Access Scope
4.2.3.
Threat: Malicious Client Obtains Existing Authorization by Fraud
4.2.4.
Threat: Open Redirector
4.3.
Token Endpoint
4.3.1.
Threat: Eavesdropping Access Tokens
4.3.2.
Threat: Obtaining Access Tokens from Authorization Server Database
4.3.3.
Threat: Disclosure of Client Credentials during Transmission
4.3.4.
Threat: Obtaining Client Secret from Authorization Server Database
4.3.5.
Threat: Obtaining Client Secret by Online Guessing
4.4.
Obtaining Authorization
4.4.1.
Authorization "code"
4.4.1.1.
Threat: Eavesdropping or Leaking Authorization "codes"
4.4.1.2.
Threat: Obtaining Authorization "codes" from Authorization Server Database
4.4.1.3.
Threat: Online Guessing of Authorization "code"s
4.4.1.4.
Threat: Malicious Client Obtains Authorization
4.4.1.5.
Threat: Authorization "code" Phishing
4.4.1.6.
Threat: User Session Impersonation
4.4.1.7.
Threat: Authorization "code" Leakage through Counterfeit Client
4.4.1.8.
Threat: CSRF Attack against redirect-uri
4.4.1.9.
Threat: Clickjacking Attack against Authorization
4.4.1.10.
Threat: Resource Owner Impersonation
4.4.1.11.
Threat: DoS Attacks That Exhaust Resources
4.4.1.12.
Threat: DoS Using Manufactured Authorization "codes"
4.4.1.13.
Threat: Code Substitution (OAuth Login)
4.4.2.
Implicit Grant
4.4.2.1.
Threat: Access Token Leak in Transport/Endpoints
4.4.2.2.
Threat: Access Token Leak in Browser History
4.4.2.3.
Threat: Malicious Client Obtains Authorization
4.4.2.4.
Threat: Manipulation of Scripts
4.4.2.5.
Threat: CSRF Attack against redirect-uri
4.4.2.6.
Threat: Token Substitution (OAuth Login)
4.4.3.
Resource Owner Password Credentials
4.4.3.1.
Threat: Accidental Exposure of Passwords at Client Site
4.4.3.2.
Threat: Client Obtains Scopes without End-User Authorization
4.4.3.3.
Threat: Client Obtains Refresh Token through Automatic Authorization
4.4.3.4.
Threat: Obtaining User Passwords on Transport
4.4.3.5.
Threat: Obtaining User Passwords from Authorization Server Database
4.4.3.6.
Threat: Online Guessing
4.4.4.
Client Credentials
4.5.
Refreshing an Access Token
4.5.1.
Threat: Eavesdropping Refresh Tokens from Authorization Server
4.5.2.
Threat: Obtaining Refresh Token from Authorization Server Database
4.5.3.
Threat: Obtaining Refresh Token by Online Guessing
4.5.4.
Threat: Refresh Token Phishing by Counterfeit Authorization Server
4.6.
Accessing Protected Resources
4.6.1.
Threat: Eavesdropping Access Tokens on Transport
4.6.2.
Threat: Replay of Authorized Resource Server Requests
4.6.3.
Threat: Guessing Access Tokens
4.6.4.
Threat: Access Token Phishing by Counterfeit Resource Server
4.6.5.
Threat: Abuse of Token by Legitimate Resource Server or Client
4.6.6.
Threat: Leak of Confidential Data in HTTP Proxies
4.6.7.
Threat: Token Leakage via Log Files and HTTP Referrers
5.
Security Considerations
5.1.
General
5.1.1.
Ensure Confidentiality of Requests
5.1.2.
Utilize Server Authentication
5.1.3.
Always Keep the Resource Owner Informed
5.1.4.
Credentials
5.1.4.1.
Enforce Credential Storage Protection Best Practices
5.1.4.2.
Online Attacks on Secrets
5.1.5.
Tokens (Access, Refresh, Code)
5.1.5.1.
Limit Token Scope
5.1.5.2.
Determine Expiration Time
5.1.5.3.
Use Short Expiration Time
5.1.5.4.
Limit Number of Usages or One-Time Usage
5.1.5.5.
Bind Tokens to a Particular Resource Server (Audience)
5.1.5.6.
Use Endpoint Address as Token Audience
5.1.5.7.
Use Explicitly Defined Scopes for Audience and Tokens
5.1.5.8.
Bind Token to Client id
5.1.5.9.
Sign Self-Contained Tokens
5.1.5.10.
Encrypt Token Content
5.1.5.11.
Adopt a Standard Assertion Format
5.1.6.
Access Tokens
5.2.
Authorization Server
5.2.1.
Authorization "codes"
5.2.1.1.
Automatic Revocation of Derived Tokens If Abuse Is Detected
5.2.2.
Refresh Tokens
5.2.2.1.
Restricted Issuance of Refresh Tokens
5.2.2.2.
Binding of Refresh Token to "client_id"
5.2.2.3.
Refresh Token Rotation
5.2.2.4.
Revocation of Refresh Tokens
5.2.2.5.
Device Identification
5.2.2.6.
X-FRAME-OPTIONS Header
5.2.3.
Client Authentication and Authorization
5.2.3.1.
Don't Issue Secrets to Clients with Inappropriate Security Policy
5.2.3.2.
Require User Consent for Public Clients without Secret
5.2.3.3.
Issue a "client_id" Only in Combination with "redirect_uri"
5.2.3.4.
Issue Installation-Specific Client Secrets
5.2.3.5.
Validate Pre-Registered "redirect_uri"
5.2.3.6.
Revoke Client Secrets
5.2.3.7.
Use Strong Client Authentication (e.g., client_assertion/client_token)
5.2.4.
End-User Authorization
5.2.4.1.
Automatic Processing of Repeated Authorizations Requires Client Validation
5.2.4.2.
Informed Decisions Based on Transparency
5.2.4.3.
Validation of Client Properties by End User
5.2.4.4.
Binding of Authorization "code" to "client_id"
5.2.4.5.
Binding of Authorization "code" to "redirect_uri"
5.3.
Client App Security
5.3.1.
Don't Store Credentials in Code or Resources Bundled with Software Packages
5.3.2.
Use Standard Web Server Protection Measures (for Config Files and Databases)
5.3.3.
Store Secrets in Secure Storage
5.3.4.
Utilize Device Lock to Prevent Unauthorized Device Access
5.3.5.
Link the "state" Parameter to User Agent Session
5.4.
Resource Servers
5.4.1.
Authorization Headers
5.4.2.
Authenticated Requests
5.4.3.
Signed Requests
5.5.
A Word on User Interaction and User-Installed Apps
6.
Acknowledgements
7.
References
7.1.
Normative References
7.2.
Informative References
7.3.
翻訳プロジェクト
Appendix A.
翻訳者
| TOC |
本ドキュメントでは, OAuth仕様が定めるSecurity Considerationsの範囲を超え, OAuth 2.0プロトコル [RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) に関する包括的脅威モデルを基に, さらなるセキュリティ上の検討項目を示す. 本ドキュメントは以下の項目について扱う.
ここで述べる脅威には, OAuthトークンやそれによって保護されるリソースに対する意図的な攻撃の他, 適切なセキュリティ対策が施されていない場合に起こりうるセキュリティリスクも含む. 各脅威はプロトコル仕様の構造に基づいて整理され, デベロッパーが実装時に参照しやすく考慮されている. 例えば, アクセスを許可する際の脅威や各grant typeそれぞれに固有の脅威, リソースサーバーに関わる脅威などが, 該当する章・節にまとめて紹介されている.
注) 本ドキュメントはそれぞれの脅威の発生確率や具体的なリスクについては述べない. そういった項目は, 実装やサービス内容に大きく左右されるためである. 本ドキュメントは抽象的なレベルでの議論を行うが, ここで述べられる情報は実装固有の脅威モデルを考慮する際の基礎となるであろう. 実装者には, 抽象的な脅威モデルを実際の実装にあてはめ, リスク分析を行うことが求められる. なお本ドキュメントはOAuth 2.0仕様本体を対象としており, 本ドキュメント執筆現在仕様策定が進んでいるクライアント登録やディスカバリーなどの拡張仕様については考慮しない.
| TOC |
| TOC |
本ドキュメントで述べられるSecurity Considerationsは, [RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) がサポートする, 特定のOAuthサーバーと紐づくクライアントのみを考慮する. こういった実装は以下のような特徴を持つ.
また以下の項目は対象外とする.
| TOC |
攻撃者とリソースに関して, 以下の想定を置く.
| TOC |
本セクションではセキュリティ上重要なデータに関して, OAuthの各エンティティが持ちうる機能, 制限および設計上のオプションについて仮定する. これらは脅威解析における基礎となる.
OAuthプロトコルはある程度実装に自由度を残している. Core仕様は認可サーバーとリソースサーバーの基本的なコンセプトを定めている. これら両サーバーは単一のエンティティとして実装されることもあれば, 分散した複数のエンティティとして実装される場合もある. 後者の典型例としては, 複数のサービスを提供している事業者が, 単一の認証・認可サービスを, 特にミドルウェアレベルで共通に用いるケースなどがある.
| TOC |
認可サーバーでは, 以下のデータが保存されているかアクセス可能な状態にある.
(訳注: Assertionタイプのトークンを用いる場合, redirect_uri や client_id などがトークン自体に含まれており, それらが認可サーバー上には保存されていない場合もある)
| TOC |
リソースサーバーでは, 以下のデータが保存されているかアクセス可能な状態にある.
リソースサーバーはリフレッシュトークン, ユーザーパスワードおよびクライアントシークレットは知らないものとする.
| TOC |
OAuthでは, クライアントとはリソースオーナーの代理として, リソースオーナーの認可のもとで保護リソースへのアクセスを行うアプリケーションである. Webアプリケーション, ユーザーエージェントベースアプリケーション, ネイティブアプリケーションといったクライアントタイプごとに, 実装上およびセキュリティ上の特徴は異なる. クライアントタイプとそのプロフィールについては [RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) Section 2.1 に定義されている.
クライアントでは, 以下のデータが保存されているかアクセス可能な状態にある.
| TOC |
OAuth 2.0には, ある程度プロトコルレベルで攻撃やセキュリティリスクに対する対策が施されている.
| TOC |
OAuthは広範囲に渡っていろいろな種類のトークン (アクセストークン, リフレッシュトークン, 認可コード) を用いる. トークンの表現方法としては以下の2通りがある.
- Handle (or artifact)
- "handle" ("artifact" とも呼ばれる) とは, 認可サーバー内部のデータ構造に対するある種の参照である. 内部データ構造には, ユーザーID (UID) やスコープなどのトークンの属性が含まれる. handleを用いることで, トークン無効化処理を簡略化し, 暗号化メカニズムを不要にすることができる. 一方でhandleを用いると, 検証およびトークン内容取得のために, 発行者と消費者 (認可サーバーとリソースサーバーなど) の間の通信が必須となる. これはトークンの発行者と利用者 (認可サーバーとリソースサーバーなど) が異なるエンティティである場合, パフォーマンスやスケーラビリティの点で不利である. したがってhandleは主に発行者と消費者 (認可サーバーとリソースサーバーなど) が同一エンティティである場合に用いられることになるであろう. handleトークンはしばしば "opaque" トークンと呼ばれるが, これはリソースサーバーがそのトークン自体を解読する必要がなく, 単なるトークン文字列として利用するのみだからである.
- Assertion (aka self-contained token)
- assertionとはパース可能なトークンである. assertionは典型的には有効期間, 発行対象 (audience) を持ち, 改竄防止および発行者認証のため電子署名が付けられる. SAML assertion [OASIS.saml‑core‑2.0‑os] (Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) や Kerberos ticket [RFC4120] (Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.) が例として挙げられる. assertionは典型的にはリソースサーバーに直接検証される. このときリソースサーバーと認可サーバーの間で通信を行う必要はない. これはトークンの発行者と利用者 (認可サーバーとリソースサーバーなど) が異なるエンティティである場合, パフォーマンスやスケーラビリティの点で有利である. ただしassertionを用いた場合, トークン無効化の実装はhandleを用いた場合より困難である.
リソースサーバーへのリクエストにトークンを利用する場合, 以下の2つの方法を取りうる.
- bearer token
- bearer tokenとは, それを受け取ったいかなるクライアントにも利用可能なトークンである ([RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)). トークンを所有していることのみがその利用条件であるため, エンドポイント間での通信がセキュアに保たれ, 許可されたエンドポイントのみがそのトークンにアクセスできる状態を担保することが重要である. bearer tokenは, クライアントアプリケーションにとっては (proof tokenのように) 利用に際して特別な処理を行う必要がないため便利である. bearer tokenはWeb上で single-sign-on (SSO) を行う際ブラウザで用いられるcookieと類似の特徴を持つ.
- proof token
- proof tokenは特定のクライアントにのみ利用可能なトークンである. クライアントは, トークン利用に際して毎回自身がトークン利用可能な主体であることを証明するために何らかの処理を行う必要がある. クライアントにリクエスト内容に対して特定のトークンと紐づいた秘密鍵を用いて電子署名を要求する, MACタイプのアクセストークン ([OAuth‑HTTP‑MAC] (Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed., “OAuth 2.0 Message Authentication Code (MAC) Tokens,” November 2012.)) などがその例である.
| TOC |
scopeは, 特定のトークンに紐づき, リソースサーバー, リソース, およびリソースへの操作に関するアクセス認可を示す. scopeは, OAuthにおいてアクセストークンの持つ権限を明示的に示す手段となる. scopeは, 認可サーバーとエンドユーザーが, 比較的セキュアでなく信頼度の低いと考えられるOAuthクライアントに対して, リソースへのアクセス権限を制限・制御するために用いられる. クライアントは必要に応じてトークンの権限を狭めるためだけにscopeを用いることができる. (例: セキュアでないチャネルを通じてトークンが送信される際, 潜在的リスクを軽減するためなど) 典型的には, scopeはトークンの有効期間 (lifetime) 制限と併用され, 補完関係にある.
| TOC |
"expires_in" というプロトコルパラメーターによって, 認可サーバーはアクセストークンの有効期間 (lifetime) を制限し, そのlifetimeに関する情報をクライアントに通知することができる. (lifetimeは, ユーザーの意思によって行われたり, 認可サーバーのポリシーによって決定される) このメカニズムにより, 認可サーバーが比較的セキュアでないと見なすOAuthクライアントに対して有効期間の短いトークンを発行したり, セキュアでないチャネルを利用する際に同様に有効期間を短くしたりすることができる.
| TOC |
アクセストークンはクライアントがリソースにアクセスする際に用いられる. アクセストークンには, 典型的には (数分〜数時間程度の) セッションのlifetimeをカバーする程度の短い有効期間が設定される. アクセストークンはリフレッシュトークンを用いることでリフレッシュ可能である. 有効期間の短いアクセストークンとリフレッシュトークンを併用することで, 明示的な無効化処理無しにアクセストークンの無効化が行われる可能性を高めることができる.
| TOC |
リフレッシュトークンは, 特定のクライアントに対する長期間有効な認可情報を示す. このトークンはクライアント・認可サーバー間でのみ送信される. クライアントはこのトークンを使って新しい ("refresh" された) アクセストークンを取得することができる.
リフレッシュトークンによって, アクセストークンの有効期間を短く保ちつつ, ユーザーの関与無しに長期間有効なアクセス権限を維持することができる. リフレッシュトークンは, (分散環境など) リソースサーバーと認可サーバーが同一エンティティでない場合に1つのアドバンテージをもたらす. 認可サーバーがリフレッシュトークンを無効化するだけで, 発行済アクセストークンが期限切れになった時点ですべてのアクセス権限を無効化することができるのである. この際, アクセストークンの有効期間を短く保つことは, タイムリーなアクセス権限無効化の為に重要なポイントとなる. (訳注: アクセストークンが複数のリソースサーバーに分散してしまっている状況で, それを確実に無効化するのは面倒な処理である)
リフレッシュトークンは, クライアント識別子および認可リクエストを行った特定のクライアントインスタンスに紐づいたsecretでもあり, リソースオーナー認可そのものを示すものでもある. このことは以下の認可プロセスによって保証される.
以上により, クライアントが特定のトークンの秘匿性を維持する限り, リフレッシュトークンはクライアント自身を認証するためにも用いることができる.
| TOC |
認可コード ("code") はエンドユーザー認可の取得に成功した結果として発行され, クライアントがアクセストークンおよびリフレッシュトークンを取得する際の中間物として動作する. 認可コードは以下の2つの目的で, トークンの代わりにクライアントのリダイレクトURIに送信される.
| TOC |
リダイレクトURIを用いることで, 不正クライアントの検知やフィッシング攻撃の防止に役立つ. 実際に認可リクエスト時に用いられたリダイレクトURIは, 認可コードをトークンと交換する際に提示され検証される. これにより認可コードがリダイレクタを通じて偽のクライアントに漏洩した際にも, 攻撃を防ぐことができる. 認可サーバーはパブリッククライアントおよびimplicitグラントタイプを利用するコンフィデンシャルクライアントに対しては, リダイレクトURIの事前登録を必須とし, 認可リクエスト時に指定されるリダイレクトURIを事前登録済みのそれと比較検証するべきである.
| TOC |
stateパラメーターは, リクエストとそれに対するコールバックを紐づけCSRF攻撃 (Section 4.4.1.8 (Threat: CSRF Attack against redirect-uri)) を防止するために用いられる. CSRF攻撃においては, 攻撃者は自身のリソースへのアクセスを許可し, 攻撃者に対して発行されたトークンを含むリダイレクトリクエストをユーザーに実行させる. stateパラメーターはユーザーエージェントと紐付けられ, ユーザーエージェントはそれをクライアントおよびユーザーエージェントのみにアクセス可能な場所に保存する. (例: same-originポリシーによって保護された場所)
| TOC |
認証プロトコルは一般的にエンドユーザーの代理として動作するソフトウェアコンポーネントの素性に関しては考慮しない. しかしながらOAuthはそれを考慮し, 認可委譲におけるセキュリティレベルを向上している. OAuthクライアントがユーザーが不在な状況でも動作しうるとうことも, その理由である.
OAuthでは以下のように, 一連のリクエストが同一クライアントによって実行されているかを照合するため, クライアント識別子を用いる.
クライアント識別子は, 認可サーバーがユーザーに同意を求める際に, そのクライアントに関する情報を表示するためにも用いられる. さらに特定のクライアントからのリクエスト数を制限したり, リクエストに対して課金を行う際に用いられることもある. サーバーログファイルなどで異なるクライアントからのアクセスを区別する際に用いることもできるであろう.
OAuthは, クライアントが認可サーバーに対して自身を認証する能力に基づいて, コンフィデンシャルとパブリックという2つのクライアントタイプを定義している. (例: クライアントクレデンシャルの秘匿性を保持できるかどうかなど) コンフィデンシャルクライアントはクライアントクレデンシャル (クライアント識別子と紐づいたクライアントシークレットなど) を秘匿に保つことができる, もしくはクライアントアサーション (SAML参照) や鍵暗号法などの手段によりセキュアにクライアント認証を行うことができる. なお後者のクライアントアサーション (SAML参照) や鍵暗号法を用いた手段の方が, よりセキュアであると考えられる.
認可サーバーはクライアントがシークレットを秘匿に保てるかどうか, セキュアな認証方式を利用可能かどうかなどを特定すべきである. ただしその代わりにエンドユーザーがクライアントの素性を検証することも可能である. (信頼できるアプリケーションのみをインストールするなど) リダイレクトURIは, クレデンシャルを偽のクライアントに送信することを防止するために用いられる場合もあるが, クライアントの素性を検証するために用いることはできない.
クライアントはクライアントタイプ, プロフィールおよびデプロイモデルによって以下のように分類できる. (native, webアプリケーションなど, [RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) Section 9参照)
- Deployment-independent "client_id" with pre-registered "redirect_uri" and without "client_secret"
- このケースでは, クライアント識別子は同一ソフトウェアの複数インスタンスに共通して利用される. このようなクライアント識別子はエンドユーザーの関与無しには検証できない. ネイティブアプリケーションにおいては, ユーザーにクライアントのメタ情報を提示し, ログファイル中でクライアントを区別するには十分である. このクライアント識別子に紐づくアクセス権限の無効化は, 同一ソフトウェアの全インスタンスに影響する.
- Deployment-independent "client_id" with pre-registered "redirect_uri" and with "client_secret"
- これはネイティブアプリケーションのためだけのオプションである. この分類は, クライアントシークレットが適切に保護されないため推奨されない. (Section 4.1.1 (Threat: Obtaining Client Secrets) 参照) セキュリティ上の弱点のため, このようなクライアント識別子は上記のシークレットを持たないクライアントと同レベルの信頼度となる. アクセス権減の無効化は, 同一ソフトウェアの全インスタンスに影響する.
- Deployment-specific "client_id" with pre-registered "redirect_uri" and with "client_secret"
- クライアント登録プロセスにおいて, リダイレクトURI, WebサイトURL, Webサイト名および連絡先などのクライアント属性の検証が行われることが保証される. このようなクライアントは上記のすべてのユースケースで利用可能である. このレベルは手動もしくはユーザーごとに固有の登録プロセスを伴うWebアプリケーションで実現される. ネイティブアプリケーションでこのレベルを実現するのは非常に困難である. ただし, アプリケーションのインストールが管理者によって行われ, 管理者によってクライアントの真正性が検証されているか, (アプリケーションマーケットプロバイダなどにより) end-to-endで単一エンティティによってデバイスインストールごとにクライアントクレデンシャルの生成が行われている場合には, ネイティブアプリケーションでもこのレベルを実現することは可能である. アクセス権限の無効化は, 単一のインスタンスにのみ影響する.
- Deployment-specific "client_id" with "client_secret" without validated properties
- このようなクライアントは認可サーバーによって特定トランザクション内のリクエスト (認可リクエスト, トークン発行リクエスト, リフレッシュトークン発行リクエストおよびアクセストークンリフレッシュリクエストなど) でのみ識別される. 認可サーバーはいかなるクライアント属性をもエンドユーザーに保証することはできない. 再認可時の自動認可処理は可能である. このようなクライアントクレデンシャルはクライアント属性の検証無しに自動的に生成可能である. これは特にネイティブアプリケーションには新たな選択肢となりうるであろう. アクセス権限の無効化は, 単一のインスタンスにのみ影響する.
| TOC |
このセクションではOAuth 2.0の脅威モデルを網羅的にまとめる. まず各脅威を, クライアント, 認可サーバーおよびリソースサーバーという, 攻撃対象となる各OAuthコンポーネントごとに分類する. 続いてトークン取得と保護リソースへのアクセスという, フロー単位での分類を行う. それぞれに対する対抗策は Section 5 (Security Considerations) にまとめる.
| TOC |
このセクションではOAuthクライアントに対する脅威について述べる.
| TOC |
攻撃者は以下のようにして, 特定のクライアントのシークレットにアクセスする可能性がある. (訳注: ここでの "access" は, secretが持つ権限に対するアクセスを意味し, あたかもそれを知っているかのようにして振る舞える, というニュアンス)
このような攻撃により, 以下のような影響が発生しうる.
クライアントの種類によっては, 以下のような攻撃も考えられる.
攻撃例: ソースコードまたはバイナリーからシークレットを取得
これはどのようなクライアントに対しても起こりうる攻撃である. オープンソースプロジェクトでは, 公開レポジトリにあるソースコードから直接シークレットが漏洩する可能性がある. 攻撃者にソースコードが渡らない状況でも, バイナリーからシークレットを取得することもできる. アプリケーション配布時にいかにシークレットの難読化を行っても, リバースエンジニアリングによってシークレットが漏洩する可能性は考慮すべきである.
対抗策
攻撃例: クライアントインスタンス単位で異なるシークレットを取得
攻撃者はクライアントインスタンス単位で異なるシークレットを, Webサイト (Webサーバー) や特定デバイス (ネイティブアプリケーション) から取得する可能性がある.
対抗策:
| TOC |
クライアントタイプによっては, 攻撃者にリフレッシュトークンが漏洩する経路としていくつかのパターンがある. 各サブセクションではクライアントタイプごとにそれぞれの漏洩パターンおよび対抗策をまとめるが, まずは一般的な適用可能な対抗策について述べる.
攻撃例: Webアプリケーションからリフレッシュトークンを取得
攻撃者はWebアプリケーションの脆弱性を突いてリフレッシュトークンを取得する可能性がある.
影響: Webアプリケーションでは複数ユーザーのアカウントが一括管理されているため, こういった攻撃によってそのサイト上のすべてのリフレッシュトークンが漏洩する可能性がある.
対抗策:
攻撃例: ネイティブアプリケーションからリフレッシュトークンを取得
ネイティブアプリケーションでは, リフレッシュトークンの漏洩は1ユーザーのみへの影響にとどまるケースがほとんどである.
ローカルファイルシステムからの漏洩: 攻撃者はデバイスのファイルシステムにアクセスし, リフレッシュトークンを取得する可能性がある. この攻撃のため, 攻撃者は不正なアプリケーションを経由することがある.
対抗策:
攻撃例: デバイス盗難
ホストとなるデバイス (携帯電話など) が盗難される可能性もある. このケースでは, 攻撃者は被害ユーザーのすべてのアプリケーションにアクセスできる可能性がある.
対抗策:
攻撃例: デバイスコピー
デバイス上の全データをその他のデバイスにコピーされる可能瀬がある. この場合, 後者のデバイスはあたかも前者のように振る舞う.
対抗策:
| TOC |
クライアントタイプによっては, アクセストークンが攻撃者に漏洩するいくつかのパターンがある. アクセストークンが他のアプリケーションからアクセス可能ななんらかのストレージデバイスに保存されている場合には, アクセストークンが盗まれる可能性もある.
影響: トークンがbearer tokenであり, クライアント識別に付加的なメカニズムが用いられていない場合, 攻撃者はそのトークンのscopeの範囲内でアクセスできるすべてのリソースにアクセス可能となる.
対抗策:
| TOC |
不正なアプリケーションがエンドユーザーを騙し, 認可プロセスにおいてエンベッドブラウザを使ったフィッシング攻撃によりユーザーのパスワードを盗み取る可能性がある. またエンベッドブラウザの代わりに独自のユーザーインタフェースを用いる可能性も考えられる. このような方法では, TLSなどの視覚的な信頼メカニズムをバイパスすることができるのである. エンベッドもしくは内蔵クライアントインタフェースを用いる場合, クライアントアプリケーションが本来アクセス不可能であるはずの情報 (UID/password) へアクセスできる可能性がある.
影響: クライアントアプリケーションもしくは通信自体が汚染されていると, ユーザーはそれに気がつかないであろう. またユーザーネームやパスワードなど, 認可処理の際にやりとりされるすべての情報を盗まれることとなる.
対応策:
| TOC |
オープンリダイレクタとは, 何の検証もなしにパラメーターとして指定された場所に対してユーザーエージェントをリダイレクトさせるエンドポイントのことである. 認可サーバーがクライアントに部分的なリダイレクトURIの登録 (訳注: Hostのみ, Pathの一部のみなど) を許す場合, 攻撃者はクライアントが持つオープンリダイレクタを悪用し, 認可サーバーの検証をすり抜けて認可コードまたはアクセストークンを自身のコントロール下にあるエンドポイントに送信することが可能となる.
影響: 攻撃者は認可コードやアクセストークンにアクセスすることが可能になる.
対抗策:
| TOC |
| TOC |
OAuthは認可サーバーの真正性検証は行わない. 悪意ある者はこれを逆手に取って, クライアントのリクエストを遮り, 誤った, 場合によっては不正なレスポンスを返すことができる. この攻撃はDNSやAddress Resolution Protocol (ARP) のなりすまし (spoofing) によって実現できる. OAuthや類似プロトコルは, ユーザーに対してリダイレクトされた先でパスワードを入力するという行為に慣らすという側面も持つ. そのためユーザーが注意を怠ると, Webサイトの真正性を確認せずにクレデンシャルを入力してしまうことになり, 攻撃者にユーザーのパスワードを盗む機会を与えることとなる.
対抗策:
| TOC |
エンドユーザーの認可を受ける際, エンドユーザーは要求されたscopeおよび認可相手を理解していない場合もありうる. 本来許可されるべきでないリソースへのアクセスを, 許可してしまうこともあるであろう.
対抗策:
| TOC |
認可サーバーは既に同意済みのクライアントからの認可リクエストを自動承認することも考えられる. ユーザーが認可サーバーの認可エンドポイントにリダイレクトされた際, 認可サーバーはそのユーザーが既にそのクライアントに対してアクセスを許可していることを検知し, その場合はユーザーに同意画面を表示することなく自動的にクライアントに戻すことができる.
不正なクライアントはこの機能を悪用し, 正規クライアントの代わりにここで得られる認可コードなどを取得する可能性がある.
対抗策:
| TOC |
攻撃者は認可エンドポイントとリダイレクトURIパラメーターを使って, 認可サーバーをオープンリダイレクタとして利用することができる. オープンリダイレクタとは, 何の検証もなしにパラメーターとして指定された場所に対してユーザーエージェントをリダイレクトさせるエンドポイントのことである.
影響: 攻撃者はユーザーの認可サーバーに対する信頼を逆手に取り, フィッシング攻撃を仕掛けることができる.
対抗策:
| TOC |
| TOC |
攻撃者は認可サーバーとクライアントの通信を盗聴し, アクセストークンを取得する可能性がある.
影響: 攻撃者は該当アクセストークンの持つscopeの範囲内でアクセスできるすべてのリソースにアクセス可能になる.
対抗策:
| TOC |
認可サーバーがhandleベースのアクセストークンを用いてそれをデータベースに保存している場合, この攻撃が可能になる. 攻撃者はSQLインジェクションによって認可サーバーのデータベースアクセスを取得する可能性がある.
影響: 全アクセストークンの漏洩
対抗策:
| TOC |
攻撃者は, クライアント認証時やOAuthトークンリクエスト時に, クライアント・サーバー間を送信されるクライアントクレデンシャルを盗聴することができる.
影響: クライアントクレデンシャルの漏洩は, クライアントサービスのフィッシングやなりすまし (impersonation) を容易にする.
対抗策:
| TOC |
攻撃者は, SQLインジェクション攻撃によって, 正規のclient_id/secretペアを認可サーバーのデータベースから盗み出すことができる.
影響: 全client_id/secretペアの漏洩. これは攻撃者にいかなる正規クライアントとしても動作することを許可する.
対抗策:
| TOC |
攻撃者は正規のclient_id/secretペアを推測できる.
影響: 単一client_id/secretペアの漏洩.
対抗策:
| TOC |
本セクションでは, アクセストークン取得時の各フローにおいて発生する脅威について述べる. それぞれのフローは, 認可エンドポイントおよびトークンエンドポイントにおけるレスポンスタイプとグラントタイプによって分類される.
| TOC |
| TOC |
攻撃者により, 認可サーバーとクライアントの間の通信を盗聴され, 認可コードが漏洩する可能性がある. 加えて認可コードはブラウザ経由で送信されるので, その他の方法で意図せず信頼できないサイトや攻撃者に漏洩する可能性がある.
注: SAMLプロトコル仕様 [OASIS.sstc‑saml‑bindings‑1.1] (Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed., “Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1,” September 2003.) Section 4.1.1.9.1 および [OASIS.sstc‑sec‑analysis‑response‑01] (Linn, J., Ed. and P. Mishra, Ed., “SSTC Response to “Security Analysis of the SAML Single Sign-on Browser/Artifact Profile”,” January 2005.) にこれらと同様の攻撃に関する記述がある.
対抗策:
| TOC |
認可サーバーがhandleとして認可コードをデータベースに保存した場合, この脅威が発生しうる. 攻撃者は, データベースへのアクセス権限を不正取得したり, SQLインジェクション攻撃を通じて, 認可サーバーのデータベース中から認可コードを取得できる可能性がある.
影響: 全認可コードが漏洩し, おそらくさらにそれに紐づくredirect_uriとclient_idも漏洩する.
対抗策:
| TOC |
攻撃者が正規の認可コード値を推測し, 推測値を "code" グラントとして用いてアクセストークンを取得する可能性がある.
影響: 単一のアクセストークン, およびおそらくはそれと紐づいたリフレッシュトークンの漏洩・不正取得.
対抗策:
| TOC |
不正クライアントが正規クライアントになりすましてアクセス認可を取得する可能性がある. 不正クライアントによってはスクレイピングなどによりユーザーの同意フローをシミュレートすることも考えられる.
推測: ユーザーのデバイスを不正なソフトウェアから保護する責務は認可サーバーにはない. これは該当デバイス上で動作するプラットフォームの責務であり, プラットフォームはおそらく協調動作する (アプリケーションマネージメントインフラなどの) エコシステムと共同で, その任にあたるであろう. 認可サーバーが単体として責任を持つのは, リソースサーバー上のエンドユーザーのリソースに対するアクセス制御, およびOAuthプロトコルを通じたそれらへの不正アクセスの防止である. この前提に基づき, ここで扱う脅威に対する対抗策として, 以下が考えられる.
対抗策:
| TOC |
悪意あるアプリケーションがクライアントサイトになりすまし, 認可コードを取得する可能性がある. DNSやARPのなりすましがその要因となる. このような脅威は, Webアプリケーション型のクライアントにあてはまる. そのようなクライアントのリダイレクトURIは, ユーザのブラウザが動作するローカルホストではない別の場所を指すためである.
影響: この脅威はWebアプリケーションにあてはまり, 認可コード, そして潜在的にはそれに紐づくアクセストークンおよびリフレッシュトークンの漏洩につながる.
対抗策:
このような攻撃を防ぐため, 以下のいずれかの対策を講じることを強く推奨する.
| TOC |
悪意あるアプリケーションがクライアントサイトになりすまし, クライアント上のユーザーセッションを偽装する可能性がある. DNSやARPのなりすましがその要因となる. このような脅威は, Webアプリケーション型のクライアントにあてはまる. そのようなクライアントのリダイレクトURIは, ユーザのブラウザが動作するローカルホストではない別の場所を指すためである.
影響: ブラウザ経由でコールバックエンドポイントに送信される認可コードが攻撃者に漏洩する. 攻撃者は, そこでフローを中断し, 得られた認可コードを抜き出して自らクライアントに送ることで, 保護リソースへのアクセス権限を得る. クライアントは渡された認可コードをそのままアクセストークンと交換し, 得られたアクセストークンを使って保護リソースアクセスを行う. これによって攻撃者は被害者の管理下にある保護リソースを取得したり, それを書き換えたりすることで, なんらかの利益を得る. (サードパーティーSNS上のログインボタンなどのように) OAuthが認証処理の委譲の為に用いられている場合, 攻撃者は得られた認可コードを使って被害者としてクライアントにログインできる.
注: 認可コードをアクセストークンと交換する際のクライアント認証は, この攻撃を防ぐためには利用できない. このケースでは, トークンを取得するのはあくまで正規のクライアントである.
対抗策:
| TOC |
この攻撃では, 攻撃者は認可コードグラントタイプを悪用し, 別のユーザー (被害者) に認可サーバーへのログインおよび被害者自身のリソースへのアクセス許可を行わせ, 得られた認可コードを攻撃者のアカウントを使ってクライアントに渡す. 被害者によるリソースへのアクセス認可を, クライアントサイト上の攻撃者アカウントと紐づけることが, その目的である.
攻撃者は既存クライアントを悪用し, それを自身の悪意あるサイトと組み合わせて利用する. これは被害者の「クライアントアプリケーションは特定のリソースサーバーへのアクセスを要求しているのだろう」という思い込みを利用した攻撃である. 被害者は正規クライアントから発行された正常なリクエストを目にするため, そのリクエストを受理するであろう. そして攻撃者は被害者が知らず知らずのうちに認可してしまった情報へのアクセス権限を得るのである.
この攻撃は以下のフローで行われる.
影響: 攻撃者はクライアントサイト上の自身のアカウントを通じて被害者のリソースへのアクセス権限を得る.
対抗策:
| TOC |
Cross-site request forgery (CSRF) は, Webサイトに信頼もしくは認証されたユーザーを通じてHTTPリクエストを実行させる, Webベースの攻撃である. 攻撃にはHTTPリダイレクトやHTMLフォームなどが用いられる. OAuth認可フローに対するCSRF攻撃は, 攻撃者がOAuthの保護リソースへのアクセス権限を取得する際に, ユーザー同意ステップをスキップすることを可能にする.
この攻撃は認可コードフロー中でリダイレクトURIに対して行われる. 攻撃者は, 自身の保護リソースに対する認可を行い, 認可コードを取得する. その後攻撃者は自身のデバイス上でクライアントへのリダイレクトを途中で止め, 被害者にそのリダイレクトリクエストを実行させる. リダイレクトを受けたクライアントは, 認可サーバーからトークンを取得し, クライアント上の被害者セッションとそのトークンでアクセスできるリソースを紐づける.
影響: 被害者は攻撃者の代理としてリソースアクセスを行う. その栄養はアクセスされるリソースに依存するが, 例えば被害者が攻撃者のリソースとしてプライベートなデータをアップロードするケースなどが考えられる. OAuthを3rd partyログインの為に用いている場合, クライアント上の被害者アカウントが外部Identity Provider上の攻撃者アカウントと紐づけられてしまい, 攻撃者が別デバイス上で被害者としてクライアントにログインできるようになってしまう, といったケースも考えられる.
対抗策:
| TOC |
Clickjackingとは, 不正なサイトが不可視iframe ([iFrame] (World Wide Web Consortium, “Frames in HTML documents,” December 1999.)) に対象サイトをロードし, 対象サイト上の重要なボタンに会うようにその下のレイヤーに偽ボタンを配置し, 被害者のクリックを誘導する攻撃である. ユーザーが可視ボタンをクリックすると, 実際には不可視ページ上のボタンがクリックされる. (「認可」ボタンなど)
影響: 攻撃者はユーザーの認証クレデンシャル (訳注: ID & Passwordなど) やリソースアクセスを得る.
対抗策:
| TOC |
クライアントが保護リソースへのアクセスを要求する際, 通常認可フローではリソースオーナーの明示的なアクセス許可/拒否が行われる. しかしながら, 不正クライアントが認可フローの詳細を把握し, プログラムによって認可フローに必要なリクエストを実行することも考えられる. こうすることにより, クライアントはユーザー同意なしに被害者のリソースへのアクセス権限を得ることができる. 認可サーバーがユーザーインタラクションを必要としない認証手法を取ったり, 複数ページにまたがる認可フローを分割可能にしていると, このような攻撃に対して脆弱になる.
不正クライアントは不可視HTMLユーザーエージェントを利用して認可サーバーが送信するHTMLフォームを中断し, 自動的に同様のHTTP POSTリクエストを実行する. なお, このとき攻撃者は認可サーバー上でリソースオーナーの認証済セッションを利用できる必要がある. これは以下のような手段で実現可能となる.
いずれのケースでも, 攻撃は被害者のデバイス上のユーザーエージェント, もしくはネイティブアプリケーションで実行される必要がある.
注: この攻撃はCSRF対策では防止できない. 攻撃者は認可サーバー自身で構築されたnonceなどを含むURLを「実行」しているに過ぎない. (訳注: Cookieなどもすべて取られているという仮定であろう)
対抗策:
認可サーバーは自身のリスク分析に基づき, この脅威を検知および防止すべきかどうか決定すべきである.
この攻撃を防ぐため, 認可サーバーは以下のように推測不可能な入力値を伴うユーザーインタラクションを強制することも考えられる.
その他に, リソースオーナーに不正アクセスを検知させるため, 認可サーバーがアクセス認可が行われた際にリソースオーナーに適切な手段で通知するという方法も考えられる. (テキストメッセージ, インスタントメッセージ, emailなどを利用)
| TOC |
認可コードやアクセストークンが十分なエントロピーを持っておらず, ユーザーの関与やユーザーごとの認可コード/トークン数の制限無しに自動的にアクセス許可を行う場合, 攻撃者は認可リクエストを繰り返して認可サーバーの認可コード/アクセストークンプールを枯渇させることができる.
対抗策:
| TOC |
ボットネットを持つ攻撃者であれば, "http://" で始まるリダイレクトURIを収集し, それらにランダムな認可コードを付与してアクセスすることで, 認可サーバーに大量のHTTPSコネクションを集中させることができる. (訳注: クライアントのリダイレクトURIは "http://" であり, 認可サーバーの認可エンドポイントは "https://" である点がポイント) これは認可サーバーに対するDoSアタックになりうる.
この攻撃は, クライアントがCSRF対策を行ったりstateパラメーターを利用していたとしても可能である. (Section 4.4.1.8 (Threat: CSRF Attack against redirect-uri)) CSRF対策が行われている場合, 攻撃者は正規のCSRFコードやstateパラメーターを取得するため, 追加のHTTPリクエストを行えばよい. 追加のHTTPリクエストが必要になることで, 攻撃者は2倍のコストを必要とするが, HTTPSとHTTPのコスト比が2倍以上であれば, 攻撃者は認可サーバーに対してDoSアタックを成立させることができる. ([SSL‑Latency] (Sissel, J., Ed., “SSL handshake latency and HTTPS optimizations,” June 2010.) によってHTTPS/HTTPのコスト比は約3.5倍となる)
影響: 認可コードフローのこの特徴により攻撃者が得るメリットには以下のようなものがある.
対抗策:
| TOC |
攻撃者は被害者のアイデンティティを用いてアプリケーションやWebサイトにログインすることも考えられる. アイデンティティ情報をOAuthにより保護されたサービスのAPIに頼っていると, それが脆弱性につながることがあるのである. これは「ソーシャルログイン」と呼ばれるシナリオで散見されるパターンである.
前提条件として, リソースサーバーがユーザーのアイデンティティを提供するAPIを持っている必要がある. クライアントは, OAuthのアクセストークンを使ってこの「アイデンティティAPI」にアクセスし, そのレスポンスに含まれる識別子を使ってユーザーを識別する. クライアントはこの一連の操作を持ってユーザーが認証されたものとして扱う.
クライアントが認可コードグラントタイプを利用している場合, 攻撃者はクライアントが利用しているのと同じIdentity Provider (IdP) から, ターゲットとなる被害者の認可コードを取得する必要がある. このため攻撃者は, 被害者に対して, 同じIdPを通じて悪意あるアプリへログインするよう誘導する. (このアプリはIdPにとっては正規クライアントである可能性がある) それを受けてIdPはアイデンティティAPIへのアクセス権限を含む認可コードを発行する. 悪意あるアプリケーションはその認可コードを攻撃者に送り, 攻撃者はそれを受けてターゲットとなるクライアントへのログインフローを開始し, 認可レスポンスに含まれる認可コードを被害者のものに置き換える. リソースサーバーに関して言えばaudienceは正常であるため, クライアントは受け取った認可コードをアクセストークンと交換し, アイデンティティAPIにアクセスする. しかしながらアイデンティティAPIのレスポンスには被害者の識別子が含まれるため, 攻撃者はターゲットクライアント上の被害者のアカウントにログインできる.
影響: 攻撃者は特定のアプリケーションおよびそのアプリケーション内のユーザーデータにアセクセスできる.
対抗策:
| TOC |
implicitグラントタイプフローでは, アクセストークンがリダイレクトURIのフラグメントを通じて直接クライアントに渡される. HTTPユーザーエージェントはHTTPサーバーにフラグメント部分を送らないので, トークンはリダイレクトURIが指し示す対象には送られないと想定される. よってクライアント・ユーザーエージェント間の通信経路上でアクセストークンを盗聴したりHTTPリファラーヘッダー経由でトークンが漏洩することはない.
| TOC |
トークンが攻撃者に盗聴される可能性がある. トークンはリダイレクトURIのフラグメントを通じてサーバーからクライアントに渡される. この通信がセキュアで無い場合, トークンが漏洩する.
影響: 攻撃者がトークンの持つ権限を得る.
対抗策:
| TOC |
攻撃者はブラウザ履歴からトークンを取得できる. これには攻撃者が特定のデバイスにアクセスできる必要がある.
対抗策:
| TOC |
不正クライアントが詐欺によりトークンを受け取る.
クライアント認証の実施を除いては, Section 4.4.1.4 (Threat: Malicious Client Obtains Authorization) と同様の対策が可能である.
| TOC |
攻撃者がクライアントWebサーバーになりすまし, クライアント (のスクリプト) を改竄もしくは置き換える可能性がある. これはDNS/ARP Spoofingにより可能になる. Webブラウザ上にスクリプト言語で実装されたクライアントが対象となる.
影響: 攻撃者はユーザーのクレデンシャルを取得し, ユーザーのアイデンティティをも乗っ取り可能であろう.
対抗策:
| TOC |
CSRF攻撃 (Section 4.4.1.8 (Threat: CSRF Attack against redirect-uri)) はimplicitグラントフロー中のリダイレクトURIに対しても実行可能である. 攻撃者は, 事前に自身のリソースに対するアクセストークンを取得しておき, そのトークンを含むリダイレクトURIを構築することができる. その後ユーザーを騙してそのリダイレクトURIにアクセスさせることに成功した場合, クライアントにはそれを防ぐ手だてはない. 被害者は, そのクライアントに対して発行された攻撃者のアクセストークンと, 紐づけられることになるであろう.
影響: ユーザーは攻撃者のリソースへのアクセスを行う. その影響はリソースの種類によって異なるが, 例えばユーザーがプライベートなデータを攻撃者の管理下のリソースにアップロードしてしまうことなどが考えられる. OAuthが3rd-partyログインに使われている場合であれば, IdP上の攻撃者のアカウントとクライアント上の被害者アカウントが紐づけられてしまい, 攻撃者が他デバイスからでも簡単にクライアント上の被害者アカウントにログインできてしまうことになる.
対抗策:
| TOC |
攻撃者は被害者のアイデンティティを利用してアプリケーションやWebサイトにログインを試みることがある. OAuthで保護されたAPIから取得したアイデンティティデータを使ってユーザー認証を行うアプリケーションが, この脅威の対象となる. この攻撃パターンは "social login" と呼ばれるシナリオで見受けられる.
前提条件として, リソースサーバーがユーザーの個人情報を取得するためのAPIを提供しており, かつその情報を持ってユーザーのアイデンティティが得られたと見なすことができる必要がある. これはつまり, クライアントがリソースサーバーのAPIを "Identity" APIとして扱っているということである. クライアントは, OAuthのアクセストークンを使ってアイデンティティAPIにアクセスし, ユーザーのアイデンティティを取得した後, 自身が内部で持つユーザーアカウントデータ (ログイン情報) から該当ユーザーを特定する. このフローでユーザーの情報を取得できることを根拠として, クライアントは該当ユーザーが認証されたものとして扱う.
この攻撃では, 攻撃者は同じIdentity Providerがターゲットのクライアントに向けて発行した, 被害者の正規のアクセストークンを取得する必要がある. 攻撃者が被害者を騙して, ターゲットクライアントのふりをして不正アプリにログインさせるなどが, その方法となる. (この不正アプリはIdentity Providerから見ると, 正規のクライアントのように見える) こうすることで, Identity Providerの認可サーバーは該当Identity Provider用のアクセストークンを発行することになる. それを受け, 不正アプリは得られたアクセストークンを攻撃者に送信し, それをトリガーとして攻撃者はターゲットアプリのログインフローを開始する. ここで攻撃者は認可レスポンスを改竄し, 自身のアクセストークンの代わりに被害者のアクセストークンをレスポンスに含める. このトークンは, リソースサーバーに関しては正規のaudienceを持つため, アイデンティティAPIで受け入れられる. しかしアイデンティティAPIから返されるユーザー識別子は被害者のものであるため, 攻撃者はターゲットアプリに被害者としてログインできてしまう.
影響: 攻撃者は, そのアプリケーション自体へのアクセス, および被害者がアプリケーション内で持つユーザーデータへのアクセスを取得することになる.
対抗策:
| TOC |
リソースオーナーパスワードクレデンシャルグラントタイプ ([RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) Section 4.3) は, レガシーシステムからの移行のためなどにしばしば利用される. このグラントタイプでは, クライアントは自身のクレデンシャルの他に, エンドユーザーのIDとパスワードにも直接アクセスし, それらを使ってアクセストークンを取得する. このグラントタイプはUID/パスワードアンチパターンに当てはまるため, 他のグラントタイプより高リスクである. さらに, 認可プロセスはユーザーのコントロール下にないため, このグラントタイプを利用するクライアントはscopeによる制約を受けず, 潜在的にはユーザー自身と同じ権限を持ちうる. (訳注: ID & パスワードを教えた時点でおしまいということ) 認可ステップが存在しないため, トークンの無効化機能もバイパスされうる.
往々にして2つ以上のサービスで同じパスワードを使うというケースが存在するため, このアンチパターンは提供されたクレデンシャルにアクセス可能ないかなるサービスをもリスクにさらす可能性がある. さらに, 容易に同じ主体であると推測できる情報 (joe@example.com と joe@example.net のペアなど) から, 同じパスワードが違う場所で利用されていることを容易に推測可能なケースもありうる.
影響: リソースサーバーは, 特定のクライアントに紐づけられたアクセストークンベースでしかscopeの区別を付けることができない. クライアントは長期間有効なトークンを取得し攻撃者にそれを送信することもできる. クライアントおよびエンドポイントにいる主体は, ユーザーIDとパスワードを盗聴可能である.
対抗策:
| TOC |
クライアントのセキュリティが不十分な場合, 攻撃者や内部犯行者がユーザーのパスワードを取得する可能性がある.
対抗策:
| TOC |
すべてのリソースオーナーとのインタラクションは, クライアントによって行われるため, 意図の有無にかかわらず, リソースオーナーが認識しないもしくは意図していなかったscopeを持つトークンが発行される可能性がある. 例えば, リソースオーナーが, クライアントはメディアストレージへのread-onlyアクセスのみを必要としていると思ったにも関わらず, クライアントは実際にはフルアクセス権限をリクエストしていた, というようなこともありうる.
対抗策:
| TOC |
すべてのリソースオーナーとのインタラクションは, クライアントによって行われるため, 意図の有無にかかわらず, リソースオーナーの意思に反してクライアントが長期間有効なリフレッシュトークンを取得する可能性がある.
対抗策:
| TOC |
攻撃者が通信を盗聴してユーザーのパスワードを盗むことも考えられる.
影響: 1人のエンドユーザーのパスワード漏洩
対抗策:
| TOC |
データベースへの不正アクセスやSQLインジェクション攻撃などにより, 攻撃者が認可サーバーのデータベースから有効なユーザー名とパスワードのペアを盗み出すことも考えられる.
影響: 全ユーザーのユーザー名 & パスワードペアの漏洩. これは, 同じクレデンシャルを他サービスで利用しているケースなどでは, 認可サーバーのドメインを超えて影響を与える.
対抗策:
| TOC |
攻撃者が正規のユーザー名 & パスワードペアを推測し, passwordグラントとして利用することも考えられる.
影響: 1人のユーザー名 & パスワードペアの漏洩.
対抗策:
| TOC |
クライアントクレデンシャル ([RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) Section 3) は, クライアント認証のための手段 (client secretのマッチングなど) と紐づいた識別子 (secretではない) により構成される. このグラントタイプに対する脅威は, Section 4.4.3 (Resource Owner Password Credentials) で述べられたものと類似している.
| TOC |
| TOC |
攻撃者が認可サーバー・クライアント間の通信を盗聴しリフレッシュトークンを盗み出す可能性がある.
対抗策:
| TOC |
この脅威は, 認可サーバーがリフレッシュトークンをhandleとしてデータベースに保存している場合に起こりうる. 攻撃者はデータベースへのアクセス権を不正取得したり, SQLインジェクション攻撃によって, 認可サーバーのデータベースからリフレッシュトークンを取得する可能性がある.
影響: 全リフレッシュトークンの漏洩.
対抗策:
| TOC |
攻撃者が有効なリフレッシュトークンの値を推測し, それをrefresh_tokenグラントとして用いてアクセストークンを取得する可能性がある.
影響: 単一のリフレッシュトークンおよびそれを使って取得できるアクセストークンの漏洩.
対抗策:
| TOC |
攻撃者が認可サーバーへのリクエストをプロキシし, 有効なリフレッシュトークンを取得しようとする可能性がある. 認可サーバーURLはクライアント開発時で既知であるか, 少なくとも既知のリソースサーバーから取得できる状態にあることが想定されるため, 攻撃者は攻撃のためある程度のスプーフィングを必要とする.
対抗策:
| TOC |
| TOC |
攻撃者がクライアント・リソースサーバー間の通信系路上で有効なアクセストークンを取得する可能性がある. アクセストークンは認可サーバーとリソースサーバーの間で共有されるシークレット情報であるため, 他のクレデンシャル (エンドユーザーパスワードなど) と同じような保護が必要である.
対抗策:
| TOC |
攻撃者がユーザーデータを取得/改変/破壊するため, 有効なリクエストをリプレイする可能性がある.
対抗策:
| TOC |
トークンがhandleの場合, 攻撃者は他のアクセストークンから得られる情報を頼りにアクセストークンの値を推測する可能性がある.
影響: 単一ユーザーのデータにアクセスされる.
対抗策:
| TOC |
攻撃者が特定のリソースサーバーを装って, 特定の認可サーバーから発行されたアクセストークンを受け取る可能性がある. クライアントが有効なアクセストークンをこの偽リソースサーバーに送ると, サーバーはリソースオーナーの認可のもと他のサービスにアクセスできるようになる.
対抗策:
| TOC |
正規のリソースサーバーが別のリソースサーバーにアクセスしようとする可能性がある. 同じように, クライアントもまた取得したトークンを別のリソースサーバーに対して使うこともありうる.
対抗策:
| TOC |
[RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) にあるOAuth HTTP認証スキームはオプショナルである. しかしながら, [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) は認証コンテキストの識別のため Authorization および WWW‑Authenticate ヘッダーに依存し, それによってセキュリティを担保している. 特にプロキシやキャッシュなどにより, これらのヘッダーを利用しないリクエストが適切に保護されないケースがありうる. 例えば, プライベートな認証コンテキストがパブリックにアクセス可能な状態でキャッシュされるといったことが考えられる.
対抗策:
| TOC |
アクセストークンがURIクエリーパラメータとして送られる場合, トークンがログファイルやHTTPリファラーなどを通じて漏洩する可能性がある.
対抗策:
| TOC |
本セクションでは Section 4 (Threat Model) で述べた脅威を軽減するために推奨する対抗策について述べる.
| TOC |
本セクションでは, すべてのOAuthコンポーネント (クライアント, リソースサーバー, トークンサーバーおよびユーザーエージェント) に対し, 一般に適用可能な対策について考慮する.
| TOC |
これはクライアントから認可サーバーまたはリソースサーバーへ送信されるすべてのリクエスト対し適用可能である. OAuthはリクエストの完全性検証のための方式を提供するが, リクエストの秘匿性を保つための方式は提供しない. さらなる予防措置を行わない限り, 盗聴者はリクエストの中身にフルアクセスし, シークレットやトークンなどのリクエストの中身を用いて遮断やリプレイアタックを開始することが可能となる.
TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) のようなトランスポート層でのセキュリティ機構を用いることによって攻撃を軽減することが可能である. IPsec VPN [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) のような仮想プライベートネットワーク (VPN) も同様に考慮に値する. (訳注: 「transport-layer mechanisms such as TLS」は, 文脈から「transport-layer "security" mechanisms such as TLS」と見なした. )
注: 当文書では各々のプロトコルエンティティ間のコネクションがend-to-endのTLSで保護されていることを想定している. データセンターの境界などのようにTLSをオフロードすることによってこの想定から外れているデプロイは, これによって引き起こされる新たな (主に内部者による) 脅威に対処するために, この脅威モデルを改良しなければならない.
これは以下の脅威に対する対抗策である:
(訳注: アクセストークンと認可コードは, 認可エンドポイントとの通信路上も流れるが, 上記で触れらていないのは記述の漏れの可能性あり)
| TOC |
HTTPSサーバー認証や類似の手段によってサーバーのアイデンティティを認証することが可能である. その目的は, 接続の確立の際にサーバーの完全修飾ドメイン名とサーバーから提示された公開鍵とを確実に結びつけることである. ([RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) 参照)
クライアントはサーバーとそのドメイン名の結びつきを検証すべきである. その結びつきの証明に失敗した場合, その通信はman-in-the-middle攻撃を受けていると考えられる. このセキュリティ手法は, この目的においてクライアントが信頼している認証局 (CA) に依存している. クライアントはこれらの信頼するCAを慎重に選択すべきであり, 信頼するCAの証明書を格納するストレージを変更されないように保護すべきである.
これは以下の脅威に対する対抗策である:
| TOC |
リソースオーナーへの透明性は, OAuthプロトコルの鍵となる要素である. ユーザーは常に認可処理の指令者であるべきであり, 判断に必要な情報を得られるべきである. さらにいえばユーザーの関与はよりよいセキュリティ対抗策である. ユーザーは恐らくある種の攻撃に対して, 認可サーバーよりも正しく認識することができる. 認可プロセス時, 認可プロセス後, そしてユーザーが情報を得たいと思った時のいずれも, 下記のような手法を用いて情報の提示と交換を行うことができる:
| TOC |
当セクションでは未認可のアクセスや悪用からあらゆる種類のクレデンシャルを保護するための対抗策について述べる. クレデンシャルは, あらゆる種類のトークン (リフレッシュトークンやアクセストークン) や認可コード, あるいはクライアントシークレットやユーザーパスワードのような, 長寿命のシークレットである.
| TOC |
管理者はクレデンシャルのストレージ保護に関する業界のベストプラクティスを採用すべきである (例えば, [OWASP] (, “Open Web Application Security Project Home Page,” .) 参照). このようなプラクティスは以下のサブセクションの事項に限定されるものではない.
| TOC |
攻撃者がセンシティブな設定ファイルやデータベースにアクセスできないように, サーバーシステムはロックダウン (権限によりアクセス制限) されていることがある.
| TOC |
クライアント識別子やその他の認証コンポーネントをSQLデータベースに対し問い合わせたり比較する場合, 受け取ったパラメータを送信する前に検証しなければインジェクション攻撃を受ける可能性がある.
| TOC |
認可サーバーはクリアテキストでクレデンシャルを格納すべきではない. 典型的なアプローチは代わりにハッシュを格納するか, クレデンシャルを暗号化することである. (ユーザーパスワードであるため) クレデンシャルが十分なエントロピーレベルを持っていない場合, オフライン辞書攻撃を困難にするためのソルトを追加することによってストレージが強固になる.
注: いくつかの認証プロトコルは, 認可サーバがクリアテキストのシークレットにアクセスできる必要がある. サーバがハッシュにしかアクセスできない場合, これらのプロトコルを実装することができない. このようなケースの場合, クレデンシャルを強固に暗号化するべきである.
| TOC |
クライアントアプリケーションがクライアントクレデンシャルを安全に永続化していない場合, 攻撃者による取得のターゲットとなりやすい. キーストアやデータベースのような暗号化永続機構を用いてクライアントクレデンシャルを格納すること. クライアントクレデンシャルを直接クライアントコードに記述するとスキャニングに対し脆弱になる. またクライアントクレデンシャルの変更の管理が困難にもなる.
| TOC |
非対称暗号を用いれば, 認可サーバでクレデンシャル管理を行う必要はなくなる.
| TOC |
| TOC |
オンラインパスワード攻撃を困難にすることに繋がるユーザーパスワードのエントロピー増加のため, 認可サーバーは複雑なユーザーパスワードポリシーを強制することもある. 複雑にしすぎた場合, ユーザーはパスワードを再利用したり, 紙にメモしたり, 安全でない方法で格納したりする可能性があることに注意すること.
| TOC |
人間によって利用されるのではないシークレット (例: クライアントシークレットやトークンハンドル) を生成するとき, 推測攻撃のリスクを軽減するために, 認可サーバーは合理的なレベルのエントロピーを含むように生成すべきである. 認可サーバーは, 128ビット以上の暗号論的に強固な乱数または擬似乱数シーケンスからトークンの値を生成するべきである. (本ドキュメント執筆時点のベストプラクティスとして [RFC4086] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.) を参照)
| TOC |
ある一定の回数試行に失敗した場合, そのアカウントをロックすることにより, パスワードに対するオンライン攻撃を軽減することができる.
注: この手法は正規のサービスユーザーのロックダウンに悪用される可能がある.
| TOC |
ユーザー名/パスワードによる認証の試行失敗に対して, 認可サーバーはそのアカウントをロックしたり, ある一定の時間, レスポンスを遅延させることがある. この時間は, 試行失敗の回数に応じて, 増加することもある. この目的は, あるユーザー名に対する攻撃者の試行をスローダウンさせることにある.
注: これは認可サーバーのより複雑でステートフルな設計が必要となるかもしれない.
| TOC |
人間の対話が必要になることにより, このアイデアはプログラムが大規模な数のパスワードの自動チェックを行うことを防ぐ.
注: これは, ユーザーエクスペリエンスにネガティブなインパクトを与える.
| TOC |
| TOC |
認可サーバーはトークンに関連付けられたスコープの縮小または制限を決定することもある. この決定の基準は当文書のスコープ外である. 以下は例である:
認可サーバーはグラントタイプに応じて, 異なるスコープを許可することもある. 例えば, エンドユーザーと認可サーバーが直接対話することで得た認可 (つまり認可コードグラントタイプ) は, クライアントが「ユーザー名」/「パスワード」を認可サーバーに直接送信することで得た認可 (つまりリソースオーナーパスワードクレンデンシャルグラントタイプ) よりも信頼できるとみなすこともある. この手法は以下の脅威の影響を減らすことができる:
| TOC |
トークンは一般に適切な期間の経過後, 有効期限切れとなるべきである. これにより, (署名のような) 他のセキュリティ手法の補完や強化を行うことができ, あらゆる種類のトークン漏洩の影響を減らすことができる. トークン漏洩のリスクに応じて, (例えば決済トランザクションに対しては) 数分で有効期限切れとなり, (例えば連絡先情報への読み取りアクセスに対しては) 何時間も有効のままとなる.
有効期間は下記のような様々な要因により決定される:
| TOC |
短い有効期間のトークンは以下の脅威に対する対策となる:
注: トークンの有効期間を短くする場合, 認可サーバーとリソースサーバー間のより正確な時刻同期が要求される. さらにいえば, 短い有効期間はより多くの (アクセストークンの) トークンリフレッシュを必要とするかもしれないし, エンドユーザによる (認可コードとリフレッシュトークンの) 認可処理の繰り返しに繋がるかもしれない.
| TOC |
認可サーバーはトークンの利用回数を制限してもよい. これにより以下の脅威を軽減することができる:
例えば, 認可サーバーがある認可コードの交換の試行を複数回観測した場合, 現在のリクエストだけでなく, その認可コードに関連づいた全てのアクセストークンを無効化することもありうる.
認可コードと同様に, アクセストークンも操作回数に制限があってもよい. これは, クライアントアプリケーションを再認証し, 新たなアクセストークンを取得するためにリフレッシュトークンを使用することを強制するか, ユーザーも関与させてアクセストークンの再認可をクライアントに強制することになる.
| TOC |
マルチサービス環境にある認可サーバーは, 送信先として意図しているサーバーを明示的にトークン内に指定するなど, 異なるリソースサーバーに対して異なる内容のトークンを発行してもよい. SAMLアサーション ([OASIS.saml‑core‑2.0‑os] (Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) 参照) は, この目的のために Audience 要素を用いている. この対抗策は以下の状況に対して使用される:
| TOC |
トークン取得時にaudienceとしてエンドポイントURLを指定することで, リソースサーバーを指定することもできる. このトークンはリソースサーバー自身のエンドポイントURLを含むため, リソースサーバーは他のリソースサーバーからの不正アクセスを検知することができる. (訳注: 複数のリソースサーバーが1つの認可サーバーに認可を委ねており, かつリソースサーバー同士の間に信頼関係が構築できないケースに有効)
| TOC |
実装者は, 各scopeに特定のリソースサーバーに対するアクセス権限を表現させ, 各トークンが明示的にそれらのscopeを持つように設計することもできる. (訳注: 暗黙的なdefault scopeを許可しないということ) このアプローチは, リソースサーバーやクライアントが想定外の目的でトークンを利用するという攻撃を軽減することができる.
| TOC |
認可サーバーはトークンを特定のクライアント識別子に結びつけることもできる. この識別子はトークン付きの全てのリクエストに対し検証されるべきである. この手法は以下の目的で利用できる:
注: クライアント識別子の検証は, ターゲットサーバーにクライアントの識別子を認証することを要求することもある. この認証は, (例えば, 認可サーバー上に事前登録されたクライアント識別子とシークレットのような) トークンとは独立して管理されたシークレットを利用するか, あるいは (例えば, 暗号化されたトークンの中身の一部として) トークン自身と共に送ることで可能となる.
| TOC |
改竄や偽のトークンの生成を検出するために, self-containedトークンは (例えば, ハッシュベースメッセージ認証コードやデジタル署名を用いて) 署名されるべきである.
| TOC |
self-containedトークンは, 秘匿性やシステムの内部データを保護するために暗号化されるかもしれない. トークンの書式に従い, (例えば共通鍵のような) 鍵がサーバノード間で流通されなければならないかもしれない. トークンや暗号化の方法といった流通の方法を定義すべきである.
| TOC |
アサーションベースのトークンデザインを実装しようするサービス提供者は, 標準のアサーションフォーマットを採用することを強く推奨する (例えば, SAML [OASIS.saml‑core‑2.0‑os] (Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)や, JavaScript Object Notation Web Token (JWT) [OAuth‑JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.)のような).
| TOC |
アクセストークンを保護するために以下の手法が使われるべきである:
| TOC |
当セクションではOAuth認可サーバのエンドポイントに関する注意点について述べる.
| TOC |
| TOC |
認可サーバーが (例えば, 認可コードのような) 認可グラント交換リクエストを複数回検知した場合, その認可グラントに関連づいた全てのトークンを無効化することもありうる.
| TOC |
| TOC |
認可サーバーは, 適切なポリシーに基づいて, リフレッシュトークンを発行しないと決断することもありうる. リフレッシュトークンは長期間有効なクレデンシャルのため, 窃取される可能性が高いかもしれない. 例えば, 認可サーバはこのようなトークンを安全に格納できないと考えられるクライアントに対し, リフレッシュトークンの発行を拒否することもありうる.
| TOC |
認可サーバーは全てのリフレッシュトークンについて, 意図している発行先のクライアントの識別子とマッチしているかの確認処理をすべきである. 認可サーバーは同じ "client_id" がアクセストークンのリフレッシュ要求の全てに存在することをチェックすべきである. (例えばコンフィデンシャルクライアントのように) 可能な場合, 認可サーバーは各リクエストにおいてクライアントを認証すべきである.
これはリフレッシュトークンの窃取や漏洩に対する対抗策である.
注: このリフレッシュトークンと "client_id" の対応は認可なしに変更されないように保護されるべきである.
| TOC |
リフレッシュトークンローテーションは, 異なるアプリケーションやデバイスから同時に同じリフレッシュトークンが利用されることを自動的に検出し阻止することを意図している. この事態はクライアントからトークンが盗まれ, それを攻撃者と正当なクライアントの両方が用いた場合に発生する. 基本的な考えは, 古いリフレッシュトークンを用いたアクセストークン取得の試行を検出するために, 全てのリフレッシュリクエストの度にリフレッシュトークンの値を変更することである. 認可サーバーは攻撃者と正当なクライアントのどちらがアクセスしようとしているのか判断できないため, 古いリフレッシュトークンを用いたアクセス試行があった場合, 有効なリフレッシュトークンとこれに関連したアクセス認可の両方を無効化する.
OAuth仕様は, グラントタイプが "refresh_token" のときでも, 認可サーバーが新たなリフレッシュトークンをトークンレスポンスとして返すのを可能とすることでこの方法をサポートしている.
注: この方法は, 現在有効なリフレッシュトークンの使用状況を確認しなければならないため, クラスター環境では問題を引き起こす可能性がある. このような環境では, 他の方法の方がより適切であるかもしれない.
| TOC |
認可サーバーは, クライアントまたはエンドユーザーによるリフレッシュトークン無効化の明示的なリクエストを許可してもよい. トークンの無効化方法は [OAuth‑REVOCATION] (Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, “Token Revocation,” November 2012.) で仕様化されている.
これは以下に対する対抗策となる:
| TOC |
認可サーバーは認証クレデンシャルとデバイス識別子の紐付けを要求してもよい. International Mobile Station Equipment Identity [IMEI] (3GPP, “International Mobile station Equipment Identities (IMEI),” September 2012.) はこのような識別子の一例である. またOS固有の識別子も存在する. 特定のデバイスからトークンが窃取されたことを検出するために, 認可サーバーはユーザークレデンシャルの認証時にこのような識別子を含めることができる.
注: いかなる実装においてもデバイス識別子を用いることのプライバシーへの影響の可能性を考慮すべきである.
| TOC |
X-FRAME-OPTIONS ヘッダー ([X‑Frame‑Options] (Ross, D. and T. Gondrom, “HTTP Header X-Frame-Options,” October 2012.) 参照) をサーバーサイドから指定することによって, iframeでの表示を回避することを最近のブラウザに対しては強制することができる. このヘッダーは "DENY" と "SAMEORIGIN" という2種類の値を持つことができ, フレーム表示を一切禁止することと, 異なるオリジンのサイトでは禁止することをそれぞれ意味する. "ALLOW-FROM" という値を指定することができるブラウザも存在し, この場合は, iframeでの表示を許可する信頼できるオリジンのリストも併せて指定する.
これは以下の脅威に対する対抗策である:
| TOC |
Section 3 (Security Features) (Security Features) で述べたように, クライアントは以下のような様々な目的で識別, 認証, 認可される.
クライアントタイプ毎に機能や特性が異なるため, 上記の目的を達成する方法も複数ある. これらの方法について当セクションで述べる. 認可サーバー提供者はセキュリティポリシーとクライアントのデプロイについて注意し, それに従って適切に取り扱うべきである. 例えば一つの例として, 全てのクライアントは信頼できず安全ではないとみなして取り扱うといったようなことが挙げられるだろう. その対極として, サービス提供者は全てのクライアントのインストールを管理者が個々に有効化することによって, ソフトウェアパッケージのアイデンティティに対する信頼性と, このクライアントがインストールされた環境のセキュリティを確保するといった例が挙げられる. これら2つの例の間の中間的なアプローチもいくつも考えられる.
| TOC |
認可サーバーはシークレットを保護できないクライアント (パブリッククライアント) に対してシークレットを発行すべきではない. これはクライアントが強固に認証されたと認可サーバーが取り扱ってしまう可能性を減らす.
例えば, あるネイティブアプリケーションの全てのインストールで共有される単一のクライアント識別子とシークレットを生成することは, あまりよくない. このようなシナリオでは, アプリケーションマーケットのような配布チャネルを通じて, 開発者からそのアプリケーションを利用する全てのエンドユーザのデバイスに対してシークレットを伝えなければならない. アプリケーションのソースコードや関連のリソースバンドルに埋め込まれたシークレットは, リバースエンジニアリングに対しては無力である. 次に, このようなシークレットを無効化すると, そのアプリケーションの全てのインストールが即座に動作しなくなってしまうため, 無効化することができない. さらに, 認可サーバーはクライアント識別子を実際には信用できないため, そのクライアントの信頼性をエンドユーザに示すことは危険だろう.
以下のセクションで述べるように, 妥当なセキュリティレベルを達成する他の方法がある:
| TOC |
認可サーバーはパブリッククライアントに対し自動認可を許すべきではない. 認可サーバーは個々のクライアント識別子を発行するかもしれないが, 全ての認可処理はエンドユーザーによる承認を必要とすべきである. シークレットなしのクライアントは, 以下の脅威に対する対抗策である:
| TOC |
認可サーバーは "client_id" の発行と共に, その "client_id" に対し事前設定されたクライアント個別の "redirect_uri" を関連付けるかもしれない. そして, 異なるリダイレクトURIを持つ認可リクエストを受けた場合は自動的に拒否する. もしくは, 認可サーバーは認可リクエストにどのようなリダイレクトURIが設定されていたとしてもそれを無視し, 代わりに既知の事前設定されたリダイレクトURIに対して常にリダイレクトすべきである. これはシークレットを持たないクライアントにおける以下の脅威に対する対抗策である:
| TOC |
認可サーバーは, ある一つのクライアント (つまりソフトウェアパッケージ) について, インストール毎に異なるクライアント識別子とシークレットを発行するかもしれない. このようなアプローチは, "public" クライアントを "confidential" クライアントに変える効果があるだろう.
ウェブアプリケーションにとっては, これは一つの "client_id" とソフトウェアパッケージがインストールされているウェブサイト毎に異なる一つの "client_id" と "client_secret" のペアを作ることを意味するだろう. そして, その個々のサイトの提供者はウェブサイトのセットアップの際に, 認可サーバーにクライアント識別子とシークレットを要求することになるだろう. これは, そのウェブサイトのリダイレクトURIやウェブサイトURL, その他の有用な属性の検証を可能とするだろう. このウェブサイトの提供者はそのサイト上でのクライアントシークレットのセキュリティを確保しなければならない.
ネイティブアプリケーションにとっては, あるアプリケーションの様々なデバイス上における全てのコピーは異なるインストールであるため, より複雑である. このシナリオではインストール固有のシークレットとして, 以下のどちらかのパターンで "client_id" と "client_secret" を取得する必要が出てくる:
いずれのアプローチもクライアント識別子とシークレットを発行するための自動機構が必要となるであろうが, OAuthでは現状その機構を定義していない.
一つ目のアプローチはアプリケーションの真正性に対するある程度の信頼が確保できるが, 二つ目のオプションはクライアントの属性の検証ではなくインストールの真正性のみが確保される. しかしこれは少なくとも, 様々なリプレイ攻撃を防止する助けになるだろう. さらに, インストール固有のクライアント識別子とシークレットは, 特定のインストールに対する全てのリフレッシュトークンの選択的な無効化を一度で行うことを可能とする.
| TOC |
認可サーバーは全てのクライアントに "redirect_uri" を登録することを要求すべきであり, その "redirect_uri" は [RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) で定義された完全なURIであるべきである. この登録の方法については当ドキュメントの対象外である. OAuthのコア仕様のとおり, エンドユーザー認可エンドポイントへそれぞれの "client_id" と共に送信されるリダイレクトURIは, 登録されているリダイレクトURIと合致していなければならない. それが合致していなかった場合, 認可サーバーはその受信したGETリクエストは攻撃者によって送信されたものとみなし, 拒絶するべきである. 注: 認可サーバーはこのような認可リクエストのリダイレクトURIにユーザーエージェントをリダイレクトすべきではない. 事前登録された "redirect_uri" を検証することは, 以下の脅威に対する対抗策となる:
この手法の根底にある想定は, 認可コードを取得するには攻撃者がその他のリダイレクトURIを使用する必要が出てくることである. 実装者は, 攻撃者がこのセキュリティ手法を回避するために被害者のデバイスに対してなりすまし攻撃を行う可能性を検討するかもしれない.
注: クライアントの事前登録は (手動で処理する) デプロイではスケールしないかもしれない. または (まだ仕様化されていない) 動的クライアント登録を必要とするかもしれない. 動的クライアント登録がない場合, 事前登録された "redirect_uri" は開発・設定時のデプロイに紐づけられたクライアントでのみ有効に動作する. 即時の動的なリソースサーバーのディスカバリーが必要な場合は, この事前登録 "redirect_uri" ではもはや実現可能ではないかもしれない.
| TOC |
認可サーバーは漏洩したシークレットの悪用を防止するため, クライアントのシークレットを無効化するかもしれない.
注: この手段では, 対象のクライアントに発行された認可コードやリフレッシュトークンも即時にすべて無効化するだろう. これは対象のネイティブアプリケーションやウェブアプリケーションの複数のデプロイで使用されているクライアント識別子やシークレットに意図しない影響を与えるかもしれない.
これは以下に対する対抗策である
| TOC |
クライアントアサーション [OAuth‑ASSERTIONS] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” December 2012.) のような代替の認証方式を使用することによって, "client_secret" の流通が不要となる. これは, 安全な秘密鍵ストアや認証プロセス中にクライアントアサーションの発行者によって指定されたその他の追加の認証システムの使用が必要となるかもしれない.
| TOC |
当セクションではエンドユーザーの関与する認可フローに関する注意点について述べる.
| TOC |
クライアントがクライアントシークレットによる認証や, または署名された認証アサーション証明書 (Section 5.2.3.7 (Use Strong Client Authentication (e.g., client_assertion/client_token))) や事前登録されたリダイレクトURIの検証 (Section 5.2.3.5 (Validate Pre-Registered "redirect_uri")) のようなその他の認証メカニズムによる認証を受けていないとき, 認可サーバーは繰り返しの認可を自動処理すべきではない.
| TOC |
認可サーバーはエンドユーザーに認可プロセスで何が起き, 結果がどうなるかを明確に説明すべきである. 例えば, ユーザーはどのようなアクセス権をどのくらいの期間クライアントに与えようとしているかを理解すべきである. またサーバーがそのクライアントの属性 (ウェブサイトURLやセキュリティポリシー) について確実に証明できるかどうかをユーザーに明らかにすべきである.
| TOC |
認可のプロセスでは, ユーザーは典型的にはクライアントからの認可のリクエストの承認を求められる. 認可サーバーによって認識されているクライアントの名前とユーザーが利用しているウェブサイトやアプリケーションの名前が適合しているかどうかなど, クライアントの属性の検証にエンドユーザーが関与できるため, これは重要なセキュリティメカニズムである. この手法は特に認可サーバーがクライアントを認証できない状況のときに有用である. これは以下に対する対抗策である:
| TOC |
認可サーバーは全ての認可コードをエンドユーザー認可プロセスを開始したクライアントの識別子と紐づけるべきである. この手法は以下に対する対抗策である.
注: この紐づけは認可なしに変更されないように保護されるべきである (例えば, 保護メモリ および／または セキュアデータベースを使用する).
| TOC |
認可サーバーは全ての認可コードをエンドユーザー認可プロセスでクライアントへのリダイレクトの宛先として使用される実際のリダイレクトURIと紐づけできるようにすべきである. この紐づけは, クライアントが認可コードをアクセストークンに交換しようとした際に, 検証されるべきである. 攻撃者が認可コードをアクセストークンに交換する際に別のリダイレクトURIを使用することができないため, この方法は偽のウェブサイトへの認可コードの漏洩に対する対抗策となる.
| TOC |
当セクションはクライアントアプリケーションに対するSecurity Considerationsを扱う.
| TOC |
クライアントソフトウェアのコピーは多数作られるため, アプリケーションの全てのインストールで共有される単一のクライアント識別子とシークレットを生成することは, あまりよくない. クライアントシークレットが安全に保持されるとは言えないため, このようなアプリケーションはパブリッククライアントと見なされるだろう. アプリケーションのソースコードや関連のリソースバンドルに埋め込まれたシークレットは, リバースエンジニアリングに対しては無力である. 次に, このようなシークレットを無効化すると, そのアプリケーションの全てのインストールが即座に動作しなくなってしまうため, 無効化することができない. さらに, 認可サーバーはクライアント識別子を実際には信用できないため, そのクライアントの信頼性をエンドユーザに示すことは危険だろう.
| TOC |
サーバーやデータベース, 設定ファイル, その他のサーバーの運用に関わるコンポーネントの完全性を保護するために, 標準的なウェブサーバーの保護と設定方法を使うこと.
| TOC |
あらゆる種類のシークレット (トークン, クライアントシークレット) を安全にデバイスやサーバーに格納する方法は複数存在する.
ほとんどのマルチユーザーオペレーティングシステムは個々のシステムユーザーの個人ストレージをそれぞれ分離して管理している. さらに, 最近のスマートフォンのオペレーティングシステムのほとんどはファイルシステムの分離された領域にアプリケーション固有のストレージまでも用意され, 他のアプリケーションからアクセスできないようになっている. 加えて, アプリケーションはPINやパスワードといったユーザーが提供するシークレットを用いてデータの秘匿性を実現することもできる.
別の方法としてリフレッシュトークンを信頼できるバックエンドサーバーに保管する方法が挙げられる. この方法ではクライアントとバックエンドサーバー間の強固な認証機構が必要となる. 注: アプリケーションは, 秘匿データがセキュアストレージから読み出された後でも秘匿性を保持したままであることを保証すべきである. これは典型的にはこのデータをアプリケーションのローカルメモリ内で保持することを意味する.
| TOC |
典型的な最近の電話機では, デバイスを盗難された場合や置き忘れた場合に有用な追加の保護機構を持っている. これらはPINやパスワード, 顔認識のようなその他の生体情報を利用する. これらが提供するセキュリティレベルはそれぞれ同等ではない.
| TOC |
"state" パラメーターはクライアントに対する複数のリクエスト間を紐づけたり, リダイレクトURIなどに対するCSRF攻撃を防止するために使用される. 攻撃者は彼ら自身の認可コードやアクセストークンをインジェクションすることが考えられ, その結果, 被害者のではなく攻撃者の保護リソースに関連づけられたアクセストークンをクライアントに使わせることになる (例えば, 被害者の銀行口座情報を攻撃者の制御下にある保護リソースに保存).
クライアントは認可リクエストを作成する際, ユーザーエージェントの認証状態をリクエストに紐づけた値 (例えばユーザーエージェントの認証に用いたセッションクッキーのハッシュ) を認可サーバーに送るために "state" リクエストパラメーターを利用すべきである. エンドユーザーの認可が得られた後, 認可サーバーはリクエストに含まれているものと同じ値を持つ "state" パラメーターを付与し, エンドユーザーのユーザーエージェントをクライアントにリダイレクトバックさせる.
この紐づけられた値とユーザーエージェントの認証状態のマッチングを行うことにより, クライアントはリクエストの妥当性を検証することができる.
| TOC |
以下はリソースサーバーのsecurity considerationsについて詳述する.
| TOC |
AuthorizationヘッダーはHTTPプロクシとサーバーによって認識され, 特別に取り扱われる. アクセストークンをリソースサーバーに送るためにそのようなヘッダー, 特にAuthorizationヘッダーを用いることは, 一般に認証済リクエストが意図せず保存されたり漏洩する可能性を減らす.
| TOC |
認可サーバーは, トークンに特定のクライアント識別子を紐づけし, リソースアクセスの際にリソースサーバーがその紐づけを検証可能とすることもできる. その際リソースサーバーは, リクエスト送信者がトークンの正規のオーナーであることを確認するため, リクエスト送信者の認証が必要になる. この対抗策を実装する方法はいくつかある:
認証済リクエストは偽のリソースサーバーによるトークンの悪用に対する対抗策となる.
| TOC |
トランスポートレベルのセキュリティ手法の置き換えや, そのような手法の補完のために, リソースサーバーは署名されたリクエストのみを受け付けるよう決定するかもしれない. 全ての署名されたリクエストはユニークに識別できるべきであり, リソースサーバーによって二度処理されることがないようにすべきである. この対抗策は以下についての軽減を助ける:
| TOC |
セキュリティプロトコルとしてOAuthは, エンドユーザーをセキュリティモデルの一部とし, 重要なユーザー対話をフロー中に通常含んでいるという点が独特である. これが上記で説明された脅威のいくつかに対する防御の困難さを生み出している. これらの点のうちいくつかは既に説明してきたが, ここでふたたび繰り返して焦点をあてる価値はある.
| TOC |
We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu, Francisco Corella, Peifung E. Lam, Shane B. Weeden, Skylar Woodward, Niv Steingarten, Tim Bray, and James H. Manger for their comments and contributions.
| TOC |
| TOC |
| [RFC6749] | Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT). |
| [RFC6750] | Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT). |
| TOC |
| [Framebusting] | Rydstedt, G., Bursztein, Boneh, D., and C. Jackson, “Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites,” IEEE 3rd Web 2.0 Security and Privacy Workshop, May 2010. |
| [IMEI] | 3GPP, “International Mobile station Equipment Identities (IMEI),” 3GPP TS 22.016 11.0.0, September 2012. |
| [OASIS.saml-core-2.0-os] | Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-core-2.0-os, March 2005. |
| [OASIS.sstc-saml-bindings-1.1] | Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed., “Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1,” September 2003. |
| [OASIS.sstc-sec-analysis-response-01] | Linn, J., Ed. and P. Mishra, Ed., “SSTC Response to “Security Analysis of the SAML Single Sign-on Browser/Artifact Profile”,” January 2005. |
| [OAuth-ASSERTIONS] | Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” Work in Progress, December 2012. |
| [OAuth-HTTP-MAC] | Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed., “OAuth 2.0 Message Authentication Code (MAC) Tokens,” Work in Progress, November 2012. |
| [OAuth-JWT] | Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” Work in Progress, December 2012. |
| [OAuth-REVOCATION] | Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, “Token Revocation,” Work in Progress, November 2012. |
| [OPENID] | “OpenID Foundation Home Page.” |
| [OWASP] | “Open Web Application Security Project Home Page.” |
| [Portable-Contacts] | Smarr, J., “Portable Contacts 1.0 Draft C,” August 2008. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML). |
| [RFC2818] | Rescorla, E., “HTTP Over TLS,” RFC 2818, May 2000 (TXT). |
| [RFC4086] | Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” BCP 106, RFC 4086, June 2005 (TXT). |
| [RFC4120] | Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” RFC 4120, July 2005 (TXT). |
| [RFC4301] | Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” RFC 4301, December 2005 (TXT). |
| [RFC5246] | Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT). |
| [SSL-Latency] | Sissel, J., Ed., “SSL handshake latency and HTTPS optimizations,” June 2010. |
| [Sec-Analysis] | Groß, T., “Security Analysis of the SAML Single Sign-on Browser/Artifact Profile,” 19th Annual Computer Security Applications Conference, Las Vegas, December 2003. |
| [X-Frame-Options] | Ross, D. and T. Gondrom, “HTTP Header X-Frame-Options,” Work in Progress, October 2012. |
| [iFrame] | World Wide Web Consortium, “Frames in HTML documents,” W3C HTML 4.01, December 1999. |
| TOC |
| [oidfj] | OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン.” |
| [oidfj-github] | OpenIDファウンデーションジャパン, “Githubレポジトリー.” |
| [oidfj-trans] | OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ.” |
| TOC |
本仕様の翻訳は, OpenIDファウンデーションジャパン (OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン,” .) [oidfj] 翻訳・教育ワーキンググループ (OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ,” .) [oidfj‑trans]を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Githubレポジトリー (OpenIDファウンデーションジャパン, “Githubレポジトリー,” .) [oidfj‑github] にご連絡ください.
| TOC |
| Torsten Lodderstedt (editor) | |
| Deutsche Telekom AG | |
| EMail: | torsten@lodderstedt.net |
| Mark McGloin | |
| IBM | |
| EMail: | mark.mcgloin@ie.ibm.com |
| Phil Hunt | |
| Oracle Corporation | |
| EMail: | phil.hunt@yahoo.com |