Can OAuth approval process work in an IFRAME?

[Scott Carter]

I'm starting to look at the OAuth process and had a question for the
OAuth folks at Twitter.

My application BigTweet is invoked via a bookmarklet and displays as
an IFRAME on any web page that a Twitter user happens to be
browsing. Ideally I would like to be able to complete the entire
OAuth process within the IFRAME (for initial login).

I believe that Twitter recently added measures to prevent framing of
their site to stop phishing attacks. Does this extend to the OAuth
approval page? Could an exception be made for the OAuth page when
invoked from a registered application presenting a valid Request
Token? If so, could this be documented (perhaps in the OAuth Twitter
FAQ)?

The authorization page at Twitter appears to have a fairly small
content section (with Deny/Allow buttons, etc), which could fit into a
reasonably sized IFRAME. If you are agreeable to allow IFRAME
support, would it be possible to standardize on content dimensions
(for IFRAME sizing) and document this as well?

Thanks for considering my request.

Scott
http://twitter.com/scott_carter

[Ivan Kirigin]

I'd love to be able to do this also, and have mentioned it off the
list.

Imagine a "Twitter Connect" button, which would be a tiny iframe
loaded from twitter.com. If signed in, the token exchange could take
place right there. If not signed in, a new window could load with the
regular OAuth process. The callback in the button would be to a tiny
iframe acting as a confirmation of the success, loaded by the
consumer.

There is a diminished phishing risk, because the widget isn't asking
for your password. Only the new window would.

The only question is how the rest of the widget gets the notification
that the OAuth access grant has taken place. My thought is that the
widget could just ping the web service to see if things are integrated
properly. Cross domain iframe communication is a HUGE pain in the ass.
You can get around it if the twitter iframe loaded a designated hidden
iframe from the 3rd party.

Alternatively, you could ask the user to refresh the widget /
bookmarklet.

Generally, I'd like to see some standard buttons from twitter, so
normalize the OAuth experience. You can see on the top of http://tipjoy.com
a banner we made that uses twitter fonts and colors.

Best,
Ivan
http://tipjoy.com

ps check out our twitter payments api: http://tipjoy.com/api
feedback welcome!

[Joshua Perry]

The interesting thing is, that you could omit the callback URL in your
application registration with Twitter. On your site when the user
clicks the "connect twitter" button you would go and grab a request
token and pop a new window with that request token in the URI like
usual. The user would click accept and since there is not a callback
URL Twitter will say "You can close this window and complete the Connect
process". Waiting on your webpage would be the "complete connection"
button which, when clicked, would request Twitter to convert the request
token into an access token.

Instead of popping a window I don't know why you couldn't load the
Twitter authorization page into an IFrame, but the message to "close
this window" may be a bit confusing to the user.

This flow is the same as a desktop application has to use to accomplish
an OAuth connection and should work the similarly well with a web
application.

Josh

[Abraham Williams]

If you have the approval process take place in the iframe there is no way to for the user to actually verify they are interacting with twitter. if they are not logged into twitter already you are then asking users to enter username/password on a potentially unsafe site and opening up to fishing.

--
Abraham Williams | http://the.hackerconundrum.com
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from: Madison Wisconsin United States.

[Scott Carter]

I think Ivan's suggestion could answer the concern about the case
where a user needs to enter a username/password:

"If not signed in, a new window could load with the regular OAuth
process. "

For the case where the user is already logged in, there doesn't appear
to be any risk here. Consider the scenario where the IFRAME is
populating a page from a site pretending to be Twitter with an Allow/
Deny button. By clicking "Allow", nothing bad can happen. Twitter
isn't Allowing anything in this case since it wasn't their page to
begin with.

FYI - I think my case is different than Ivan's since he is discussing
a widget whereas my app lives entirely in the IFRAME. The callback
from Twitter after authorization would simply cause the IFRAME to
redirect back to a page on bigtweet.com where I could then present a
different (logged in) view for the user.

Joshua's suggestion would work, but providing IFRAME support with a
callback URL would save the user two steps - needing to close the
Authorization window, and clicking the Complete Connection button.

Scott

> Se"nt from: Madison Wisconsin United States.

[Ivan Kirigin]

Scott is correct here.

As a policy, web sites should never allow sign in through an iframe,
as even the minority of users smart enough to verify the source URL is
twitter.com can't verify it.

Ivan
http://tipjoy.com

[Brooks Bennett]

I whipped up a quick and dirty fix. Need to clean it up more, but it
works (this demo is subject to come down in the very near future)...

The page is: http://tweetchat.com/iframe

Load it into an iFrame with the following tacky script:

<iframe src="http://tweetchat.com/iframe/" style="height:400px; width:
800px; border: 10px dotted pink;"></iframe>

All I did was build the authorization link, but have it open in a new
child window via javascript. Set your application to have a callback
URL of a child page that handles the returned information, refreshes
the parent window and then closes itself.

It is the best thing I could come up with on the quick, but at least
there will be an easy way (hey even I could dream it up) to balance
security with functionality...

Brooks

On Mar 21, 12:33 pm, Ivan Kirigin <ivan.kiri...@gmail.com> wrote:
> Scott is correct here.
>
> As a policy, web sites should never allow sign in through an iframe,
> as even the minority of users smart enough to verify the source URL is
> twitter.com can't verify it.
>

> Ivanhttp://tipjoy.com

[Shannon Whitley]

I really like that, Brooks. I was worried that this type of page
might be stopped by popup blockers, but I suppose it works because
you're using a button and not a link (please confirm).

> > > > Se"nt from: Madison Wisconsin United States.- Hide quoted text -
>
> - Show quoted text -

[Matt Sanford]

Hi all,

I want to add one comment on this. If you can IFRAME it, you can
click-jack it using the opacity, z-index, some CSS positioning tricks.
Allowing the 'Yes, I want free porn' button to auto-authorize
someone's app to post as a user is a Bad Thing™. I saw the popup flow
from Brooks and that seems like a much better choice.

Thanks;
— Matt