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

目次

概要

  • 金融データへの読み取り専用アクセスに適したOAuthプロファイル
    • OpenID Connect(OIDC)を使用して顧客(ユーザ)を識別
    • トークンを使用して、エンドポイントから保護データを読取
    • エンドポイントは、JSONデータを提供するREST API

※ ドラフト 4 を参考にして作成。その後、ドラフト 6 を再度完読して加筆・修正。

要約

フロー

このプロファイルを簡単に説明すると、クライアントごと、以下のようになる。

Confidentialクライアント

Publicクライアント

OAuth PKCE を使用する。

  • 「ハッシュ関数」には、「S256」を使用する。
  • アプリケーション間通信」には、「Claimed Https Scheme URI Redirection」を使用する。

通信

  • SSL/TLS(TLS 1.2以降)
  • redirect_uri(完全一致)

認証

ユーザ

LoA 2

  • パスワードは1024以上の組み合わせがあること。
  • IDは公的な証明書を確認して作成する。

クライアント

追加のクライアント認証の実装が必要。

トークン種類

Bearer Token(持参人切符)

役割

Authorization Server

認証・認可

  • LoA 2
  • 認可画面が必要(ここで scope の一覧を表示する)。

クライアント認証

  • クライアント種別
  • 使用する鍵
  • クライアント認証で
    • 共通鍵を使用する場合、
      client_secretを使う場合、 UTF-8 オクテットは128ビット以上が必要。
    • 公開鍵を使用する場合、
      RSAの場合、2048ビット以上、Elliptic Curveの場合、160ビット以上。

redirect_uri

  • 事前登録が必要
  • 認可リクエストに必須
  • 完全一致が必要
  • httpsのURIスキーマであること。

codeとtoken

  • code
    未使用であること。
    ≒一度だけ有効にする。
  • token
    • scopeのリストを含む
    • 有効時間は一度の利用に十分な、若しくは、非常に短い期間に限定
    • 最小128ビットの推測不可能な値(構造化アクセストークンを妨げるものではない)

追加の機能

Client

Confidentialクライアント

  • 暗号要件
    • RSA暗号を使用する場合、最小2048ビットのRSA鍵。
    • Elliptic Curve暗号を使用する場合、最小160ビットの楕円曲線キー
    • 対称鍵暗号を使用する場合、クライアントの秘密鍵が128ビット以上

Publicクライアント

  • この代替として、S256のOAuth PKCEをサポート
    • Authorization Server毎にredirect_uriを変える。
      (対応が一致しない場合は、この認証・認可プロセスを中止する)
    • 必要に応じてOAuth PKCE中でIDトークンを取得する(併用可能)。
    • ただし「アプリケーション間通信」に要件がある。
      • Private-Use URI Scheme Redirectionはダメ
      • Loopback Interface Redirectionもダメ
      • Claimed Https Scheme URI Redirectionのみ利用可

HTTP

  • その他、以下のオプションを追加できる。
    • x-fapi-auth-dateヘッダ
      Resource Ownerが最後にログインした時刻を指定
    • x-fapi-customer-ip-addressヘッダ
      Resource OwnerのIPアドレスを提供する。

Resource Server

HTTP

  • リクエスト
  • Dateヘッダ
    サーバ日付を送信
  • HTTP GETメソッドの使用をサポート
  • Client ≠ Resource Serverの場合、
    必要に応じてCORSなどをサポート
  • レスポンス
  • UTF-8でエンコード
  • Content-Typeヘッダ
    Content-Type: application/json; charset=UTF-8
  • x-fapi-interaction-idヘッダ
    • issか、金融機関のルーティング番号
    • Requestにある場合、Responseにも設定。
    • Requestにない場合、GUIDを生成して設定。
    • このid値は、ログに出力する。

Accessトークン

  • 認証ヘッダを使用し、QueryString?は使用しない。
  • 期限切れ、失効、スコープ等の検証を行う。
  • OAuth 2.0 Token Introspectionを併用可能。

セキュリティに関する考慮事項

  • Requestオブジェクトを使用すべき場合、Part 2を使用する。
    • メッセージソース認証
    • メッセージ整合性保護
    • メッセージの封じ込め
      • WWWブラウザからの漏洩
      • WWWログからの漏洩
  • ISO / IEC 29100のプライバシー原則に従う。

考察

プロファイルの識別方法

  • 既存の(クライアント認証無しの)Flowは拒否しないといけない?
    OpenID Connectのように、「scope="* openid *"」などの識別方法が提要されていないため)
  • stateに何か細工するなどしても良いかもしれないが、
    基本的に1つのclient_idに1つのプロファイルを割り当てればイイか。

参考

関連仕様

ただしOAuth2 / OIDCを除く。

FAPI Part 2 (Read and Write API Security Profile)

JWT bearer token authorizationグラント種別

OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-28 (日) 19:44:44 (50d)