マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

OAuth 2.0 の脅威モデルとセキュリティ考慮事項 (RFC 6819)

  • OAuth 2.0 の実装にあたり、脅威モデルとセキュリティ考慮事項を列挙
  • セクション4以降からの内容で、OAuth 2.0 の前提は飛ばしている。

脅威モデル

OAuth 2.0の包括的なグループ化された脅威モデル。

Role毎

Flow毎

Access毎

セキュリティ考慮事項

脅威を緩和するために推奨される対策。

General

Role毎

ざっくり

対策

漏洩対策

  • SSL/TLS(サーバ証明)を利用する。
  • 正規のClientへ発行されたトークンの漏洩に注意。
    • code(state):code置換攻撃が可能。
    • access_token:access_tokenを利用可能。

エンドポイント防御

  • stateを付与・検証する。
  • redirect_uri 検証を行う。
  • クライアント認証を行う。

トークン堅牢化

  • トークン
    • refresh_token
    • access_token
    • code
    • , etc.
  • 低いエントロピーの値を使用しない。
  • バインドする。
    • Client(aud: client_id)
    • Resource Owner(sub: sub)
    • Resource Server(aud: client_id or Endpoint)
  • access_tokenをJWT化する。

トークン検証

  • JWT化した場合、)Client、Resource Serverでも、
  • 署名検証する。
  • クレームセット検証する。
    • iss(issuer)
      issは署名検証があるので偽装困難
    • aud(client_id)
      Resource Serverでもaudによるクライアント検証を行う。
    • sub(ユーザID)
      ユーザへの明示に加え、
      Client、Resource Serverで認証済みリクエストでsub検証するなど。
  • クレームセット検証する。
    • iss(issuer)
    • aud(client_id)
    • sub(ユーザID)
    • jti(無効化状況)
  • クレームセットをJSONで返却
    Client、Resource Serverで検証を容易にする。

ユーザの教育

  • 偽造サーバの識別
  • 組み込みブラウザに注意

注意

オープン・リダイレクタ

  • 完全なredirect_uriの事前登録と検証
  • スターターとアクセストークン・リクエストでのredirect_uriの要求

自動再認証、認可画面非表示

  • 悪意のあるクライアントと組み合わさる。
  • その際のscopeなど注意が必要。

クライアント登録機能

  • 悪意のあるクライアントが容易に登録可能。
  • 悪意のあるクライアント対策の実装が必要。

パブリック・クライアント

ネイティブアプリやJSアプリのようにsecretを秘匿に保てないタイプ。

  • サーバより脅威が多い。
    • 盗難
    • リエンジ
    • ストレージ
    • ウィルス
    • 脆弱性
  • JSアプリ(SPA)の場合は、
    Implicit Flowを使用する。
  • ネイティブの場合は、
    OAuth PKCEを利用する。

参考


Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-11-22 (木) 11:51:08 (25d)