Merge pull request #38 from philippederyck/pdr/move-inbrowser-flows

Moved new section on in-browser flows

Author: aaronpk

draft-ietf-oauth-browser-based-apps.md

@@ -885,6 +885,18 @@ Authorization servers MUST require an exact match of a registered redirect URI
 as described in {{oauth-security-topics}} Section 4.1.1. This helps to prevent attacks targeting the authorization code.
 
 
+
+##### Security of In-Browser Communication Flows {#in_browser_communication_security}
+
+In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.
+In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows.
+
+If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a. {{WebMessaging}}) instead of top-level redirections.
+To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in {{WebMessaging}}).
+
+Section 4.18. of {{oauth-security-topics}} provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks.
+
+
 ##### Cross-Site Request Forgery Protections {#pattern-oauth-browser-csrf}
 
 Browser-based applications MUST prevent CSRF attacks against their redirect URI. This can be
@@ -1407,21 +1419,6 @@ and the countermeasures mentioned above.
 
 
 
-
-Security of In-Browser Communication Flows {#in_browser_communication_security}
---------------------------------------
-
-In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.
-In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run hidden iframe-based flows.
-
-If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a. {{WebMessaging}}) instead of top-level redirections.
-To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in {{WebMessaging}}).
-
-Section 4.18. of {{oauth-security-topics}} provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks.
-
-
-
-
 IANA Considerations   {#iana}
 ===================