OAuth Wrap Web App Profile まとめ

ちょっくら、OAuth Wrap Web App Profile をシーケンス図にまとめてみた。

＃こんなの、spec自体に入っていてほしいんですが…。

注意点：

wrap_client_id と wrap_client_secret は、事前に AuthzServer より WebAppClient に割り当てられています。
Access Token は、Resource と AuthzServer の間で取り決められた、Opaque な文字列で、Bearer Token （所持人払いToken）として機能します。
すべての通信はHTTPSで行うため、署名は必要ないということになっています。[*1]

WebAppClient: Service Request
WebAppClient–>UA: Verification Code Request
note over UA, WebAppClient
302 Redirect
wrap_client_id
wrap_callback
(wrap_client_state)
(wrap_scope)
(Additional Parameters)
end note
UA->AuthzServer: Verification Code Request
AuthzServer–>UA: PoP Page
UA->AuthzServer: PoP (User Authentication)
AuthzServer–>UA: Verification Code Response
note over UA,WebAppClient
302 Redirect
wrap_verification_code
(wrap_client_state)
(additonal params)
end note
UA->WebAppClient: Verification Response
WebAppClient->AuthzServer: POST Access Token Request
note over WebAppClient,AuthzServer
wrap_client_id,
wrap_client_secret
wrap_verification_code
wrap_callback,
(Additional Parameters)
end note
AuthzServer->AuthzServer: Check
note right of AuthzServer
1. Client Secret must
match that of client_id
2. client_id must match the
client_id obtained over redirect
3. verification code MUST match
that over authz redirect
4. callback must match
5. verification code MUST NOT
have expired
end note
AuthzServer–>WebAppClient: Access Token Response
note over WebAppClient,AuthzServer
200 OK
wrap_refresh_token
wrap_access_token
(wrap_access_token_expires_in)
(Additional parameters)
end note
WebAppClient->Resource: Request Resource
note over WebAppClient,Resource
Authorization: WRAP access_token=access_token_str
end note”>

[*1] セキュリティ上の疑問

まだよく考えていないのですが、少々セキュリティ上の疑問があります。

UAにRedirectしているところで、UAが man-in-the-middle となって改ざんしてしまう可能性がある。（例：UAが malware にやられちゃっているような場合。）これは、署名をRequestに施すか、あるいは Artifact のようなものにしてしまわないと対抗できないので、ちょっとこのままでは問題ありではないか？
clientを認識するために、client_id と client_secret を使っているが、client_secret は long term shared secret だ。これって、セキュリティ的にOK？少なくとも NIST SP800-63rev1的には Level 1 相当では？。
Access Token も Long Term Secret だなぁ。
HTTPSでやっていても、MITMはあるよなぁ。何を持って正しいアクセス先と認識するかもプロファイルでちゃんと書かなきゃですよね。Certificate Chain は必要条件でしかない。このへん、かなりちゃんとやらないと、リプレイ攻撃の対象になる。
Access Token は Opaque String となっているけど、このランダムさだとか、署名だとかがちゃんとしてないと、推測攻撃や偽造攻撃の対象になる。
これだけだと、Browser Swap / CSRF 攻撃の対象となりそう。

まだ、7. Security Considerations が書かれていないので、著者達がどう考えているのかわかりませんな。

あと、直接セキュリティの話じゃないんですが、以下のような疑問点もあります。

なんで、wrap_client_id と wrap_client_secret なんて配るの？
前者は XRDのSubjectとPubkeyでいいじゃん。するってぇと、client_secret の問題もなくなるし。あ、でも、そうすると、署名が復活しちゃうか…。
Scopeの書き方って標準化しないのかな？AuthzServer側は良いけど、WebAppClient側は、対象となるAuthzServerごとに、かき分けなきゃならなくなる。これは負荷だ。

@_Nat Zone

OAuth Wrap Web App Profile まとめ

いいね:

関連

コメントを残すコメントをキャンセル

共有:

いいね:

関連

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル