Yes. Token Binding enforces that only the right browser can send the token; in this browser, CORS enforces that only the correct origin can send the token.
Am 25.11.18 um 19:46 schrieb Torsten Lodderstedt: > Does this mean the RS effectively relies on the user agent to enforce the > sender constraint (via CORS policy)? > >> Am 23.11.2018 um 14:54 schrieb Neil Madden <neil.mad...@forgerock.com>: >> >> Thanks for doing this Daniel, I think the proposed text is good. >> >> — Neil >> >>> On 22 Nov 2018, at 14:42, Daniel Fett <danielf+oa...@yes.com> wrote: >>> >>> Hi all, >>> >>> I would like to discuss a text proposal for the security BCP. >>> >>> Background: >>> >>> Yesterday, Neil pointed out the following problem with binding access >>> tokens using mTLS or token binding in SPAs: >>> >>> "I am talking about scripts from places like ad servers that are usually >>> included via an iframe to enforce the SOP and sandbox them from other >>> scripts. If they get access to an access token - e.g. via document.referrer >>> or a redirect or some other leak, then they still act within the same TLS >>> context as the legitimate client." >>> >>> The problem is that a browser's TLS stack will attach the proof of >>> possession no matter which origin started a request. >>> >>> (This seems like a real downside of token binding - why does it not have >>> the "same site" option that cookies nowadays have?) >>> >>> I prepared the following addition to the security BCP and would like to >>> hear your opinions: >>> >>> "It is important to note that constraining the sender of a token to a web >>> browser (using a TLS-based method) does not constrain the origin of the >>> script that uses the token (lack of origin binding). In other words, if >>> access tokens are used in a browser (as in a single-page application, SPA) >>> and the access tokens are sender-constrained using a TLS-based method, it >>> must be ensured that origins other than the origin of the SPA cannot misuse >>> the TLS-based sender authentication. >>> >>> The problem can be illustrated using an SPA on origin A that uses an access >>> token AT that is bound to the TLS connection between the browser and the >>> resource server R. If AT leaks to an attacker E, and there is, for example, >>> an iframe from E's origin loaded in the web browser, that iframe can send a >>> request to origin R using the access token AT. This request will contain >>> the proof-of-posession of the (mTLS or token binding) key. The resource >>> server R therefore cannot distinguish if a request containing a valid >>> access token originates from origin A or origin E. >>> >>> If the resource server only accepts the access token in an Authorization >>> header, then Cross-Origin Resource Sharing (CORS) will protect against this >>> attack by default. If the resource server accepts the access tokens in >>> other ways (e.g., as a URL parameter), or if the CORS policy of the >>> resource server permits requests by origin E, then the TLS-based token >>> binding only provides protection if the browser is offline." >>> >>> >>> The "summary" above this text reads as follows: >>> >>> "If access tokens are sender-constrained to a web browser, the resource >>> server MUST ensure that the access token can only be used by the origin to >>> which the access token was issued (origin binding). One solution for the >>> resource server to accomplish this is to only accept the access token in an >>> Authorization header (as described in RFC 6750) and to ensure that the >>> active CORS policy prevents third parties from sending Authorization >>> headers. See <xref target="pop_tokens"/> for details." >>> >>> What do you think? >>> >>> -Daniel >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
