Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Third-party authentication / nested iframes #4

Closed
hober opened this issue Apr 28, 2020 · 7 comments · Fixed by #5
Closed

Third-party authentication / nested iframes #4

hober opened this issue Apr 28, 2020 · 7 comments · Fixed by #5
Labels
addition represents a feature addition

Comments

@hober
Copy link
Collaborator

hober commented Apr 28, 2020 •
edited
Loading

Lots of sites embed an iframe from a different origin that handles authentication for them. This is sometimes a third party, or maybe it's a separate service run by the same party. One obvious example is icloud.com, which uses apple.com for authentication.

Should we support such cases? If so, why, and how would the spec need to change? If not, why not?
@hober hober added the addition represents a feature addition label Apr 28, 2020
@hober hober mentioned this issue Apr 28, 2020
Merged
@samuelgoto
Copy link
Collaborator

Should we support such cases? If so, why, and how would the spec need to change? If not, why not?

Good question. We chose to deliberately ignore this problem early on because we didn't find enough demand that outweighted the risk / complexity, but happy to reopen this discussion if you find important.

Questions:

  • what other alternatives have you considered? in the icloud.com use case with apple.com, would SameSite or FirstPartySites help?
  • from a demand perspective, who is pulling this?
  • how would this work once third party cookies get further constrained?
  • from a spec perspective, should this go into whatwg/html or wicg/WebOTP instead?
  • what would prevent largely deployed widgets (say, an ad network) from sending SMSes to track users?

@hober
Copy link
Collaborator Author

hober commented Apr 29, 2020

Should we support such cases? If so, why, and how would the spec need to change? If not, why not?

Good question. We chose to deliberately ignore this problem early on because we didn't find enough demand that outweighted the risk / complexity, but happy to reopen this discussion if you find important.

We've had a few customers/clients ask for this.

  • what other alternatives have you considered? in the icloud.com use case with apple.com, would SameSite or FirstPartySites help?

It might help for cases where it's the same organization, but the third-party authentication service case is more common, and FPS wouldn't help with them. (I also doubt FPS is a good idea to add to the platform in general.)

  • from a demand perspective, who is pulling this?

I don't understand the question.

  • how would this work once third party cookies get further constrained?

I don't understand what third party cookies (or cookies in general) have to do with this. Could you elaborate?

  • from a spec perspective, should this go into whatwg/html or wicg/WebOTP instead?

I don't think so. This spec should define the format and any delivery-mechanism-agnostic usage guidance. If there were additional guidance specific to one of the delivery mechanisms, then that mechanism's spec should do that.

  • what would prevent largely deployed widgets (say, an ad network) from sending SMSes to track users?

Why would a user provide such a code to such an iframe?

@samuelgoto
Copy link
Collaborator

One obvious example is icloud.com, which uses apple.com for authentication.

how would this work once third party cookies get further constrained?

I don't understand what third party cookies (or cookies in general) have to do with this. Could you elaborate?

In the use case you mentioned, which origin is the recipient of the OTP? apple.com? that is, i'm assuming the setup is something along the lines of:

// owned by icloud.com
<html>
  <iframe src="apple.com">
    <input autocomplete="one-time-code">
  </iframe>
</html>

And the SMS is formatted more or less like:

@icloud.com @apple.com #1234

Is that the right setup?

If so, is it fair to assume that the apple.com iframe is receiving the SMS OTP? Is the apple.com iframe communicating with the icloud.com top level frame? If so, how? postMessage? Out of band? if in-band, i'm assuming the apple.com domain isn't getting any access to its third party cookies?

@majido
Copy link
Member

majido commented Oct 15, 2020 •
edited
Loading

I like to get a resolution on syntax and semantic for this proposal here as we are looking into implementing this in Chrome (crbug) as well. I am told that Safari is supporting this usecase starting from iOS14. So landing on a consensus sooner is better.

Syntax

Option 1

@top #code %iframe

As proposed in earlier PR.
I am told that Safari in iOS14 is already supports this syntax. So this is the de-facto standard at this point but perhaps it can change if there is interest to do so.

Pros:

  • Already ships in Safari
  • Backward compatible with any implementations that meets current spec and ignores any value after @top #code

Cons:

  • Different prefix token for two components that are origins (i.e., top and iframe)
  • The "audience" of the otp is divided to both before and after the code
  • A new token '%' is used.

Option 2

@top #code @iframe

Similar to Sam's proposal here but more backward compat to existing spec compliant implementations

Pros:

  • Use same prefix token for origin components (i.e., top and iframe)
  • Backward compatible with any implementations that meets current spec and ignores any value after @top #code

Cons:

  • Requires change to Safari's implementation
  • The "audience" of the otp is both before and after the code

Option 3

@top @iframe #code

This is Sam's proposal

Pros:

  • Use same prefix token for origin components (i.e., top and iframe)
  • The "audience" of the otp is both before and after the code

Cons:

  • Backward incompatible with any implementations that meet the current spec and ignores any value after @top #code
  • Requires change to current Safari's implementation

Backward Compat Concern on changing syntax

If we decide on either (2) or (3) then we have to think carefully about backward compat during the transition period. I have some ideas on how to make such a transition easier but there are challenges. But if there is interest/possibility to go for (2) or (3) then we can come up with more concrete plan here.

Nesting level

Is the intention only to allow one level nesting or are we going to allow arbitrary nesting? For example consider this nesting "top > iframeA> iframeB", does iframe B get access to WebOTP feature?

I suspect we prefer arbitrary as I don't yet see any compelling reason to limit it to just one. So yes!

If this is so then should the sms include any intermediate iframe domain as well (e.g., @top #code %iframeA %iframeB)? The current proposed PR only talks about top level origin and embedded origin.

The answer to this may also be factor into syntax consideration as well since if we allow arbitrary having a single token for all domains may make more sense. We may also want to remove any "ordering" between origins.

@yi-gu yi-gu mentioned this issue Nov 27, 2020
Closed
@erynofwales
Copy link

I think Option 2 in @majido's previous comment is a great way to go. I like that we're preserving backward compatibility with the ordering of fields. Using the same sigil for top-level and iframe domains makes sense here too.

To the iframe ordering question, I don't think we need to be completely explicit about the ordering. It seems sufficient to make sure that the URLs of all involved frames, from the page down to the frame containing the one-time code field, match one of the @ fields. I suspect the vast majority of cases will not need more than two @ fields in an SMS, but it seems reasonable to me for the parser to allow as many as the service requires to validate the chain of frames.

@majido
Copy link
Member

majido commented Jan 20, 2021 •
edited
Loading

That is great. I think we should move forward with Option 2.

I am also fine with limiting to two origins but allowing arbitrary nesting levels. Our current implementation is slightly stricter than that. In particular when we receives an OTP sms such as @A #code @B we apply the following requirements:

  • A and B has to be the head and tail of the nesting chain respectively i.e., the top frame has to be A, and the receiving frame has to be B. So A > B is valid but B > A is not.
  • A and B can nest itself as many times as needed i.e., A>B, A>A>B, A>B>B, A>A>B>B are valid but A>B>A, or A>B>A>B are not.
  • No other origin should be present in between them i.e., A>C>B is not valid.

I don't recall why we made it more restrict but I will try to dig and find out and share the rationale.

So I think we should be able to move forward with adding this to the spec.

@yi-gu
Copy link
Contributor

yi-gu commented Jan 20, 2021

The chain limitation (A>B>A not supported) was mainly due to the lack of demand and UX complexities which brings me to my following questions w.r.t. some privacy / security concerns.

Should users be aware of the iframe?

e.g. a user is visiting shop.com but when they interact with the OTP they are actually interacting with payment.com which may be against their intention. Should the user be informed of such implication? According to the linked PR:

If the above steps returned "site", it might be prudent to indicate the [=origin-bound one-time code=]'s top-level and embedded origins to the user when assisting them

IIUC it suggests that we inform users of both origins. Besides, the current spec has stronger wording. Is the proposed change intentional?

Should the top frame have full control of which embedded iframe is allowed to send SMS?

e.g. shop.com embeds two iframes payment.com and ads.com. The intent is to allow payment.com to send SMSes and complete the verification flow. But can a compromised ads.com do the same? If so, this may lead to some attack vector discussed here

I understand that this spec should focus on the format and delivery-mechanism-agnostic. Hopefully the questions above are not out of scope.

@yi-gu yi-gu mentioned this issue Jan 28, 2021
Closed
1 task
@yi-gu yi-gu mentioned this issue Feb 8, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
addition represents a feature addition
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

One possible way to handle the nested iframe case. WICG/sms-one-time-codes
5 participants
@hober @samuelgoto @erynofwales @majido @yi-gu