I put together a sequence diagram of the OAuth Wrap Web App Profile.

# I wish something like this were included in the spec itself…

Notes:

  1. The wrap_client_id and wrap_client_secret are assigned to the WebAppClient by the AuthzServer in advance.
  2. The Access Token is an opaque string agreed upon between the Resource and the AuthzServer, and it functions as a Bearer Token.
  3. Since all communication takes place over HTTPS, signatures are considered unnecessary.[*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>I have not thought this through thoroughly yet, but I have a few security questions.</p>
<ol>
<li>At the point where the request is redirected to the UA, the UA could act as a man-in-the-middle and tamper with it. (For example, if the UA has been compromised by malware.) This cannot be countered without signing the request or turning it into something like an artifact, so isn’t leaving it as is a bit problematic?</li>
<li>The client_id and client_secret are used to identify the client, but the client_secret is a long-term shared secret. Is that acceptable from a security standpoint? Under NIST SP800-63rev1, wouldn’t this be equivalent to Level 1 at best?</li>
<li>The Access Token is also a long-term secret.</li>
<li>Even when using HTTPS, MITM attacks are still possible. The profile also needs to spell out how the correct access destination is identified. A certificate chain is only a necessary condition. Unless this area is handled very carefully, it will be vulnerable to replay attacks.</li>
<li>The Access Token is defined as an opaque string, but unless its randomness, signature, and related properties are sound, it will be vulnerable to guessing and forgery attacks.</li>
<li>With only this, it seems vulnerable to Browser Swap / CSRF attacks.</li>
</ol>
<p>Section 7, Security Considerations, has not been written yet, so we do not know what the authors are thinking.</p>
<p>Also, although these are not directly security issues, I have the following questions.</p>
<ol>
<li>Why distribute things called wrap_client_id and wrap_client_secret?<br />
The former could just use the XRD Subject and Pubkey. That would also eliminate the client_secret problem. Ah, but then signatures would come back…</li>
<li>Will the way Scope is written not be standardized? It is fine on the AuthzServer side, but on the WebAppClient side it would have to be written differently for each target AuthzServer. That is a burden.</li>
</ol>
<section class=

Related posts