OAuth Wrap Web App Profile Summary

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:

wrap_client_id and wrap_client_secret are provisioned from the AuthzServer to the WebAppClient in advance.
An Access Token is an opaque string whose format is agreed upon between the Resource and AuthzServer. It acts as a Bearer Token.
All the communication is done over HTTPS so signatures are said to be unnecessary. (I am skeptical on it though. [*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] Security Questions

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.

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.
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.
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.
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.
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.
Browser Swap / CSRF attack has to be thwarted.

Much of these needs to be dealt with Section 7. Security Considerations.

In addition, I have not understood

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.
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.

.Nat Zone

OAuth Wrap Web App Profile Summary

Like this:

Related

Leave a Reply Cancel reply

Share this:

Like this:

Related

Leave a Reply Cancel reply