OAuth Wrap Web App Profile Summary

Nat January 11, 2010 No Comments

Here is the Sequence Diagram of OAuth Wrap Web App Profile (Section 5.4).

Hope the spec to include such instead of legacy ascii diagram…
websequencediagrams.com source would do.

Notes:

  1. wrap_client_id and wrap_client_secret are provisioned from the AuthzServer to the WebAppClient in advance.
  2. An Access Token is an opaque string whose format is agreed upon between the Resource and AuthzServer. It acts as a Bearer Token.
  3. All the communication is done over HTTPS so signatures are said to be unnecessary. (I am skeptical on it though. [*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] Security Questions</p> <p>It might be because I have not spent too much time on this protocol, and I was writing this (original Japanese version) at 2:00AM, I have some questions on the security characteristics. </p> <ol> <li>UA may act as the man-in-the-middle to tamper the request. (e.g., when the UA is infested by a malware.) To me, it seems that it can only be coped by either the request to be signed or something like an Artifact is used instead of the request itself. Since the target of WRAP is to remove the signature, the Artifact seems to be the way to go. </li> <li>To identify the client, it is using client_id and client_secret. It is essentially a username/password authentication. Thus, from the NIST SP800-63 like perspective, it is only LoA1. </li> <li>Access Token is another long-term secret. Moreover, it is revealed to somebody else than the client and the verifier (AuthzServer). It has some implication from the SP800-63 perspective.</li> <li>MITM is possible even for HTTPS. How to recognized that the counter party is the right one needs to be specified in more details. Certificate Chain verification is only a necessary condition. If it is not done correctly, it will be possible to mount token capture and replay attack. </li> <li>Access Token is specified only as an Opaque String. This actually needs to be specified a little more in detail. For example, randomness requirements, signature requirements etc. are needed to thwart the guessing attack and the access token forgery. </li> <li>Browser Swap / CSRF attack has to be thwarted. </li> </ol> <p>Much of these needs to be dealt with Section 7. Security Considerations. </p> <p>In addition, I have not understood </p> <ol> <li>Why are we provisioning wrap_client_id and wrap_client_secret out of band? The y can just be Subject and Pubkey of XRD. If we do so, the long-term client_secret problem disappears, though signature resurfaces. </li> <li>Why do not we standardize on Scope format? For AuthzServers, having no standard is ok, but for WebAppClients, it is much easier to code on the standard than code a proprietary request per AuthzServer.</li> </ol> <div class=

Share this: