「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- Financial API (FAPI)の「Read and Write API用セキュリティ・プロファイル」
- 金融データへのトランザクション・アクセスに適したOAuthプロファイル
- OpenID Connect(OIDC)を使用して顧客(ユーザ)を識別
- トークンを使用して、エンドポイントから保護データを読取
- エンドポイントは、JSONデータを提供するREST API
※ ドラフト 4 を参考にして作成。その後、ドラフト 6 を再度完読して加筆・修正。
要約 †
- 以下の攻撃に対するコントロールを規定
- 認可要求の改ざん
- コードインジェクション
- 状態インジェクション
- トークン要求フィッシング
- 認可応答の改ざん
フロー †
このプロファイルを簡単に説明すると、以下のようになる。
Confidentialクライアント †
Publicクライアント †
- SPA
- code id_token toke(Hybrid Flow)
- 共通
- 個別
パラメタ †
- code id_token token
SPA系のPublicクライアントの場合
- 8.3.3. Identity provider (IdP) mix-up attackの可能性がある。
- 故に、Implicit Flow より Hybrid Flow
JARMであればHybrid Flowでなくてもいい。
request or request_uri †
- JWS署名
- ES256(ECDSA using P-256 and SHA-256, Recommended+)
- PS256(RSASSA-PSS using SHA-256 and MGF1 with SHA-256, Optional)
追加クレーム †
切り離された署名 †
の値を検証する。
- 値
- state 値のASCII表現のオクテットのハッシュの左端の半分をbase64urlエンコーディング
- ハッシュはIDトークンのJOSEヘッダのalgパラメタで使用されるアルゴリズム。
- 例:algがHS512の場合
- state値をASCIIエンコードし、
- SHA-512でハッシュ化し、
- 左端の256ビットを切り出し、
- base64urlエンコードする。
通信 †
SSL/TLS †
- TLSバージョン1.2以降
- TLSサーバ証明書チェック
- 暗号スイート
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
redirect_uri †
(完全一致)
認証 †
ユーザ †
LoA 3
- 特定される⾝元識別情報の信⽤度が「相当程度ある」。
- パスワードだけではなく、2要素以上を用いてユーザー認証をする。
クライアント認証 †
トークン種類 †
記名式トークン(Proof-of-possession Token)
対象 †
- code
- token
- access_token
- refresh_token
紐付け(トークン・バインディング) †
紐付け(トークン・バインディング)のために以下の何れかをサポートする必要がある。
(記名は、Resource Owner単位ではなくてClient単位)
役割 †
Authorization Server †
先ずは、「FAPI Part 1 (Read Only API Security Profile)」に準拠。
認証・認可 †
redirect_uri †
- 事前登録が必要
- 認可リクエストに必須
- 完全一致が必要
code, token †
- 記名式トークン
- code
- token
- access_token
- refresh_token
Client †
先ずは、「FAPI Part 1 (Read Only API Security Profile)」に準拠。
共通 †
- 紐付け(トークン・バインディング)のために以下の何れかをサポートする必要がある。
Confidentialクライアント †
Publicクライアント †
- SPA系は、Hybrid Flowをサポート
- Nativeは、S256のOAuth PKCEをサポート
- 「ハッシュ関数」には、「S256」を使用する。
- 「アプリケーション間通信」には「Claimed Https Scheme URI Redirection」を使用する。
- 各カギは、
- SPA系は、クライアント端末ごとになる。
- Nativeは、インストール(インスタンス)毎になる。
Resource Server †
先ずは、「FAPI Part 1 (Read Only API Security Profile)」に準拠。
Publicクライアントダケと思っていたが、Confidentialクライアントでも必要である模様。
- これにより、Clientが指定したrequest_uriへの要求をサポートする必要が無い。
- request_uri形式は、以下の何れかだが、URNになるのが既定と考える。
- パラメタ
- Requestオブジェクトには、すべてのパラメタを同梱する(※ expクレームを含める必要がある)。
- 仕様で要求されている場合、一致した重複を更に送信しても良い。
登録リクエスト †
どうも、この(specの)コンテキストからすると、
POST https://as.example.com/ros/ HTTP/1.1
Host: as.example.com
Content-Type: application/jws
Content-Length: 1288
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
(... abbreviated for brevity ...)
zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
※ クライアント認証は、JWT中のissに対応した署名検証で行う。
Response †
- 正常
HTTP/1.1 201 Created
Date: Tue, 2 May 2017 15:22:31 GMT
Content-Type: application/json
{
'iss':'https://as.example.com/', // AuthZのID
'aud':'s6BhdRkqt3', // ClientID
'request_uri':'urn:example:MTAyODAK', // urn(暗号ランダム値)
'exp':1493738581 // 有効期限(存続期間は短く、好ましくは一回限
}
- 異常
- Authorization Required
401 Unauthorized HTTP error
署名検証が失敗した場合。
- Invalid Request
400 Bad Request HTTP error
Requestが無効
- Method Not Allowed
405 Method Not Allowed HTTP error
POST要求を使用しなかった場合
- Request Entity Too Large
413 Request Entity Too Large HTTP error
要求サイズが上限を超える場合。
- Too Many Requests
429 Too Many Requests HTTP error
ある期間にClientからの要求数が上限を超えた場合。
認可リクエスト †
request_uriをパラメタに指定して認可リクエストをおこなうダケ。
OAuth 2.0 Pushed Authorization Requestsが標準化されている。
考察 †
プロファイル †
関連仕様 †
ただしOAuth2 / OIDCを除く。
参考 †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth