[OpenID] Flash based authentication?

[Peter Williams]

>From another Peter:

Flash based objects are an important part of "BoA" SiteKey. The role of flash objects is well understood in a client auth role (when combined with other mechanisms).

One still needs server auth, of course - which needs to be independent of "browser" constructs (like address bars). But, I don't think there is any point arguing that here : they are decided that the address bar is magical. Assume one part of the brain for recognition, rather than the part that sitekey uses.

Peter.


From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Michael Graves
Sent: Friday, March 20, 2009 11:28 AM
To: general at openid.net
Subject: [OpenID] Flash based authentication?

Pete,

We've done a lot of work with Flash (AS3) widget machinery and OpenID authentication, and we expect to have a Flash component added to the RPX service we run, facilitating the kinds of interactions you're talking about here.

First, as you point out, any embedded Flash object is subject to the scope of its container (an HTML page, or maybe a Flash/Flex container inside an HTML page) -- when the top level browser location changes, you're done. Since the browser handles redirects, persisting the Flash object is not an option, and when you go from "submit" to "handle an authenticated sign in" redirect, you're starting from scratch. Typically, that's OK, since that is a move from anonymous/guest mode to a "signed in" mode where the authenticated user's profile data has been summoned from the database and is used to "personalize" the page, and possibly the flash content, via flashvars.

Anyway, the idea I wanted to raise is using Flash's "Shared Object", their private "cookie" system, built into the player. If I understand you, that may be a useful way to "bridge" the sessions when filling out big forms. The amount of storage is limited (but can be substantial, ~100k is not uncommon) and is controlled by the user. But having wrestled with this problem a bit, that works well -- when the user needs to "refresh" their session, you may be able to just store all the work in progress for the form in a Flash shared object and send the user on their way to be directed to an OP, and redirected back with a freshly authenticated session. When the user returns, the saved form data will still be available in the stored shared object, enabling the form to be "reconstituted" to the state it was in previously, partially filled out by the user.

If I'm off base as to the amount of data you need to save (big uploads, etc., more than Flash shared objects will store for that user), then this won't help. Just wanted to  point that out, as that's been a very useful feature in our work on Flash-enabled OpenID apps. Flash player 10 also has local file system access now, which is another option, and wouldn't be subject to the user-set storage limits of the shared object.

Best,

-Mike




Yeah thanks for that.

This is the one reference I have seen to someone using OpenID in a flash

context (and even better for me, a flex component).

However, the live example he has I can't seem to get to load properly in

my browser, and the demo says this upon submission of my identity:

"Ideally, this is the handler where you send "ivt.com.au/openid/peter<http://ivt.com.au/openid/peter>"

for discovery to your backend. You could then call

OpenIDLoginWindow.closeLogin(), use the response from discovery along

with ExternalInterface.call() to communicate this URL with javascript so

that the browser window is redirected there."

The key phrase being "so that the browser window is redirected there",

which will:

a) break my requirement for not destroying the flash session (need to

keep the player instance open so that everything stays in memory).

b) Quite possibly cause problems with pop-up blockers.

cheers,

Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090320/fe374a35/attachment-0001.htm>