identity

OAuth Wrap Web App Profile まとめ

Nat 2010/01/11 No Comments

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

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

注意点：

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

UA->WebAppClient: Service Request<br /> WebAppClient–>UA: Verification Code Request<br /> note over UA, WebAppClient<br /> 302 Redirect<br /> wrap_client_id<br /> wrap_callback<br /> (wrap_client_state)<br /> (wrap_scope)<br /> (Additional Parameters)<br /> end note<br /> UA->AuthzServer: Verification Code Request<br /> AuthzServer–>UA: PoP Page<br /> UA->AuthzServer: PoP (User Authentication)<br /> AuthzServer–>UA: Verification Code Response<br /> note over UA,WebAppClient<br /> 302 Redirect<br /> wrap_verification_code<br /> (wrap_client_state)<br /> (additonal params)<br /> end note<br /> UA->WebAppClient: Verification Response<br /> WebAppClient->AuthzServer: POST Access Token Request<br /> note over WebAppClient,AuthzServer<br /> wrap_client_id,<br /> wrap_client_secret<br /> wrap_verification_code<br /> wrap_callback,<br /> (Additional Parameters)<br /> end note<br /> AuthzServer->AuthzServer: Check<br /> note right of AuthzServer<br /> 1. Client Secret must<br /> match that of client_id<br /> 2. client_id must match the<br /> client_id obtained over redirect<br /> 3. verification code MUST match<br /> that over authz redirect<br /> 4. callback must match<br /> 5. verification code MUST NOT<br /> have expired<br /> end note<br /> AuthzServer–>WebAppClient: Access Token Response<br /> note over WebAppClient,AuthzServer<br /> 200 OK<br /> wrap_refresh_token<br /> wrap_access_token<br /> (wrap_access_token_expires_in)<br /> (Additional parameters)<br /> end note<br /> WebAppClient->Resource: Request Resource<br /> note over WebAppClient,Resource<br /> Authorization: WRAP access_token=access_token_str<br /> end note”></p> <p>[*1] セキュリティ上の疑問</p> <p>まだよく考えていないのですが、少々セキュリティ上の疑問があります。</p> <ol> <li>UAにRedirectしているところで、UAが man-in-the-middle となって改ざんしてしまう可能性がある。（例：UAが malware にやられちゃっているような場合。）これは、署名をRequestに施すか、あるいは Artifact のようなものにしてしまわないと対抗できないので、ちょっとこのままでは問題ありではないか？</li> <li>clientを認識するために、client_id と client_secret を使っているが、client_secret は long term shared secret だ。これって、セキュリティ的にOK？少なくとも NIST SP800-63rev1的には Level 1 相当では？。</li> <li>Access Token も Long Term Secret だなぁ。</li> <li>HTTPSでやっていても、MITMはあるよなぁ。何を持って正しいアクセス先と認識するかもプロファイルでちゃんと書かなきゃですよね。Certificate Chain は必要条件でしかない。このへん、かなりちゃんとやらないと、リプレイ攻撃の対象になる。</li> <li>Access Token は Opaque String となっているけど、このランダムさだとか、署名だとかがちゃんとしてないと、推測攻撃や偽造攻撃の対象になる。</li> <li>これだけだと、Browser Swap / CSRF 攻撃の対象となりそう。</li> </ol> <p>まだ、7. Security Considerations が書かれていないので、著者達がどう考えているのかわかりませんな。</p> <p>あと、直接セキュリティの話じゃないんですが、以下のような疑問点もあります。</p> <ol> <li>なんで、wrap_client_id と wrap_client_secret なんて配るの？<br /> 前者は XRDのSubjectとPubkeyでいいじゃん。するってぇと、client_secret の問題もなくなるし。あ、でも、そうすると、署名が復活しちゃうか…。</li> <li>Scopeの書き方って標準化しないのかな？AuthzServer側は良いけど、WebAppClient側は、対象となるAuthzServerごとに、かき分けなきゃならなくなる。これは負荷だ。</li> </ol> <div class=Pin