Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

[Karsten Meyer zu Selhausen | Hackmanit <[e-mail]>]

That's an interesting use-case for relay mode and might be a reason to 
cover it.

However, we believe the current code for the relay mode in 
draft-sakimura-oauth-wmrm-01 does not work. The same-origin policy 
should prevent this line from working:

messageTargetWindowReference = 
e.source.document.getElementById(web_message_target);

"e.source" references the main window (e.g., client.example.com). This 
means the (un)authenticated window (e.g., as.example.com) tries to 
access "document.getElementById" for the cross-origin main window.
Due to the SOP the browser should throw a DOMException ("Failed to read 
a named property 'document' from 'Window': Blocked a frame with origin 
"https://as.example.com" from accessing a cross-origin frame.")

As I said in the other response, we would be really interested in taking 
a look at existing implementations of draft-sakimura-oauth-wmrm-01 to 
see how they solve this problem.


Best regards,
Karsten


On 10.01.2024 10:15, Filip Skokan wrote:
>
>     We do not consider the relay mode. The relay mode is motivated by
>     the use of the implicit grant which is discouraged nowadays.
>
>
> Motivation aside, if my memory serves right (and that's a big IF in 
> this case), the relay mode was not limited to implicit responses and 
> was useful regardless of the response type, e.g. in cases where the 
> authorization request was triggered from an eTLD+1 top level window 
> but the target was authenticating a service that ran on its subdomain, 
> a landing page with a CTA to login sort of setup.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 10 Jan 2024 at 09:47, Filip Skokan <[e-mail]> wrote:
>
>         our draft covers and is compatible to what's called "simple
>         mode" (both with and without prompt) in
>         draft-sakimura-oauth-wmrm-00/-01.
>
>
>     So a client that's using a simple mode with web_message today
>     could, without change, utilize your draft as well? That doesn't
>     seem likely given the message structure is not the same as in
>     draft-sakimura-oauth-wmrm. Is that an omission or intentional?
>
>     S pozdravem,
>     *Filip Skokan*
>
>
>     On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen |
>     Hackmanit <[e-mail]> wrote:
>
>         Hello Filip,
>
>         our draft covers and is compatible to what's called "simple
>         mode" (both with and without prompt) in
>         draft-sakimura-oauth-wmrm-00/-01.
>
>         We do not consider the relay mode. The relay mode is motivated
>         by the use of the implicit grant which is discouraged nowadays.
>
>         The main differences to draft-sakimura-oauth-wmrm-01 can be
>         summarized as follows:
>
>           * In general we do not focus on "modes" but instead on the
>             actual communication using the postMessage API. Our draft
>             contains examples for the format/structure for the
>             messages sent using the postMessage API.
>           * Our draft enables iframe flows with user interaction while
>             draft-sakimura-oauth-wmrm-01 only covers iframe flows
>             without user interaction.
>           * Our draft contains security considerations describing
>             threats and giving recommendations to address them.
>           * Our draft briefly discusses the implications of the 3rd
>             party cookie phaseout for iframes.
>
>         Our main motivation is the belief that there is a need for a
>         specification defining how to securely use the postMessage API
>         for OAuth auth. responses. The research of my co-authors
>         underlines this need [1].
>
>         As I said, at the last OSW there was agreement that it would
>         be a good idea to write an RFC for a postMessage-based
>         response mode. draft-sakimura-oauth-wmrm-00 was expired years
>         ago and seemed to be inactive when we started to work on our
>         own draft. In our opinion it is not a great option to rely on
>         an expired draft. As for customers I work with this is not an
>         option at all; they want to implement and use final RFCs
>         whenever possible.
>
>         We are looking for feedback from the WG and are open to
>         collaborate with the authors of draft-sakimura-oauth-wmrm if
>         they want to join the efforts.
>
>
>         Best regards,
>         Karsten
>
>         [1] https://distinct-sso.com/
>
>         On 04.01.2024 12:10, Filip Skokan wrote:
>>         Hello Karsten,
>>
>>         Can you summarize in what ways is your draft compatible
>>         with draft-sakimura-oauth-wmrm-00? Which of the described
>>         modes in Nat's document does it cover?
>>
>>         There are existing implementations (both partial and full)
>>         of draft-sakimura-oauth-wmrm-00 so if your draft is not
>>         compatible I would recommend not using the same response mode
>>         name/identifier in your proposal.
>>
>>         What prompted you to start a new draft rather than
>>         using draft-sakimura-oauth-wmrm-00?
>>
>>         S pozdravem,
>>         *Filip Skokan*
>>
>>
>>         On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen |
>>         Hackmanit <[e-mail]> wrote:
>>
>>             Hi all,
>>
>>             we would like to ask again for feedback on our draft for
>>             the "web_message" response mode:
>>             *https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
>>             *
>>
>>             We think it would be very helpful for implementers and
>>             developers to specify a secure standard for a postMessage
>>             API-based response mode.
>>
>>             Best regards,
>>             Karsten*
>>             *
>>
>>             On 23.11.2023 10:11, Karsten Meyer zu Selhausen |
>>             Hackmanit wrote:
>>>
>>>             Hi everyone,
>>>
>>>             at the last OSW the topic of a response mode based on
>>>             the postMessage API came up. This approach is already
>>>             used by multiple parties (e.g., Google) but lacks
>>>             standardization.
>>>
>>>             There was some sense of agreement that it would be a
>>>             good idea to create an RFC defining this response mode
>>>             to counter security flaws in individual implementations
>>>             and improve interoperability.
>>>
>>>             Because the efforts in the past were long expired (draft
>>>             -00 of
>>>             https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/
>>>             expired in 2016) we took the initiative and started to
>>>             work on a new ID for the "web_message" response mode.
>>>
>>>             *We would like to to ask the members of the working
>>>             group for feedback on our draft:
>>>             https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/*
>>>
>>>
>>>             I see that "draft-sakimura-oauth-wmrm" has been recently
>>>             updated. However, there have not been any changes to its
>>>             contents. What are the plans of the authors for this draft?
>>>
>>>             Best regards
>>>             Karsten
>>>
>>>             -- 
>>>             Karsten Meyer zu Selhausen
>>>             Senior IT Security Consultant
>>>             Phone:	+49 (0)234 / 54456499
>>>             Web:	https://hackmanit.de  | IT Security Consulting, Penetration Testing, Security Training
>>>
>>>             Multi-Factor Authentication (MFA) significantly increases the security of your accounts.
>>>             Learn in our blog posts what the best MFA options are and how FIDO2 goes one step further to solve the world’s password problem:
>>>             https://www.hackmanit.de/en/blog-en/162-what-is-mfa
>>>             https://www.hackmanit.de/en/blog-en/165-what-is-fido2
>>>
>>>             Hackmanit GmbH
>>>             Universitätsstraße 60 (Exzenterhaus)
>>>             44789 Bochum
>>>
>>>             Registergericht: Amtsgericht Bochum, HRB 14896
>>>             Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
>>
>>             -- 
>>             Karsten Meyer zu Selhausen
>>             Senior IT Security Consultant
>>             Phone:	+49 (0)234 / 54456499
>>             Web:	https://hackmanit.de  | IT Security Consulting, Penetration Testing, Security Training
>>
>>             Multi-Factor Authentication (MFA) significantly increases the security of your accounts.
>>             Learn in our blog posts what the best MFA options are and how FIDO2 goes one step further to solve the world’s password problem:
>>             https://www.hackmanit.de/en/blog-en/162-what-is-mfa
>>             https://www.hackmanit.de/en/blog-en/165-what-is-fido2
>>
>>             Hackmanit GmbH
>>             Universitätsstraße 60 (Exzenterhaus)
>>             44789 Bochum
>>
>>             Registergericht: Amtsgericht Bochum, HRB 14896
>>             Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
>>
>>             _______________________________________________
>>             OAuth mailing list
>>             [e-mail]
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>         -- 
>         Karsten Meyer zu Selhausen
>         Senior IT Security Consultant
>         Phone:	+49 (0)234 / 54456499
>         Web:	https://hackmanit.de  | IT Security Consulting, Penetration Testing, Security Training
>
>         Multi-Factor Authentication (MFA) significantly increases the security of your accounts.
>         Learn in our blog posts what the best MFA options are and how FIDO2 goes one step further to solve the world’s password problem:
>         https://www.hackmanit.de/en/blog-en/162-what-is-mfa
>         https://www.hackmanit.de/en/blog-en/165-what-is-fido2
>
>         Hackmanit GmbH
>         Universitätsstraße 60 (Exzenterhaus)
>         44789 Bochum
>
>         Registergericht: Amtsgericht Bochum, HRB 14896
>         Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
>
-- 
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de  | IT Security Consulting, Penetration Testing, Security Training

Multi-Factor Authentication (MFA) significantly increases the security of your accounts.
Learn in our blog posts what the best MFA options are and how FIDO2 goes one step further to solve the world’s password problem:
https://www.hackmanit.de/en/blog-en/162-what-is-mfa
https://www.hackmanit.de/en/blog-en/165-what-is-fido2

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz