Please support a more traditional login flow

[st3fan]

BrowserID currently requires a 'full' browser because it depends on javascript, frames and popup windows.

My request is to support a more classic login flow where an app can simply redirect to BrowserID.org/login?callback=http://myapp.com/foo and browserid will redirect back to the application on the specified callback, passing it the assertion. The app can then verify the assertion as usual and proceed.

This has the advantage that BrowserID will work with minimal effort on more limited browsers like for example Android and iOS applications that simply open a WebView or browser on devices that simply do not have the UI to support popup windows. Or third party iOS browsers that generally do not support popup windows.

This will also greatly improve things for native applications that run just BrowserID in a webview. They can then pass a callback with a custom protocol that can be captured by the native app more easily. This is a common technique on both Android and iOS.

[benadida]

@st3fan importantly, this has the big disadvantage that it ties down everything to browserid.org, which is a centralized architecture we want to move away from.

I think we should explore better SDKs for mobile without forcing a centralization of the protocol.

[st3fan]

I understand. Maybe browserid.org can just be the springboard and do the discovery and redirect to another service if needed?

[gerv]

st3fan: can sites even detect that they are in a UIWebView, as opposed to Mobile Safari? Would you have to detect that the popup open failed?

benadida: only, surely, for limited capability browsers? Which are always going to need the browserid.org JS shim anyway, so rely on browserid.org.

[st3fan]

@gerv Yeah we can probably detect that.

[benadida]

@gerv @st3fan so one idea I've had is that I think we can detect when window.open fails and have our JS shim do a redirect flow based on the same API in that case. We need to prototype this, but what do you think?

(note that this would also help things work in Chrome for iOS, which has a funky window.open due to iOS restrictions.)

[shane-tomlinson]

Closing as same fix as #2034

[eevee]

I don't think #2034 has quite addressed the same problem. I love the idea of browserid but am absolutely unwilling to make an otherwise static-ish website require client scripting just to log in.

Would it be possible to allow a site to implement its own discovery-redirect-springboarding, doing the usual JS work on the server side without needing to rely on browserid.org?

[shane-tomlinson]

@eevee - could you explain your idea and the reasons why you'd like to do the scripting server side in more detail?

[kayaelle]

One thing we'd love to do is integrate Persona better into our user profile set up. It'd be great if we could reques a user email address & password along with other profile info and request validation/sign-up to Persona server side. We could serve the results, let them know of any errors and inform the user that an email will be sent for verification. If the Persona sign-up/login process can be integrated into to a site rather than through js modals I think it will help us align ux/branding better and reduce the amount of steps to get our users to sign up. Currently our users must have a persona account to use the Open Badges backpack. They're struggling with understanding what Persona has to do with our site and their badges. We provide instructional content but they're getting stuck.

All that said, I have a feeling I could do more reading on the Persona specs and maybe there's a better way to integrate it that I haven't figured out yet.

[seanmonstar]

@kayaelle the problem is that not everyone will be using a Persona account. Some will be using the Google account, or Yahoo, or Mozilla, or others. We don't define how they authenticate their user (which may include 2 factor auth), so we can't provide an API like that.

Some things that we've done to try to make Persona fit in the site better:

1. try using "Sign in with your Email" instead of "Persona".
2. We reduce the amount of our branding in the dialog
3. You can pass a siteLogo and backgroundColor to navigator.id.request() to make the dialog more branded to your site.

[kayaelle]

@seanmonstar - hmmm...that's good to consider. Since right now we're primarily working with the open badges backpack we don't have control over the dialog display directly. We may do as you suggest and set profiles from our site first and then send them to the backpack. Thanks for the response!

[eevee]

@shane-tomlinson I've thought on this some more and I admit a website could only store credentials used for itself, and would still need a password for securing them, so a local shim would look exactly like traditional login. But here's my half-baked train of thought.

The end goal is for browsers to have built-in support for Persona, right? At which point none of the persona.org JS even needs to be loaded, and the only JS left is a handful of calls to navigator.id methods, most of which will just do an ajax request anyway. It'd be unfortunate to rely on JS ultimately just to navigate to a URL, when this could work just as well for the common case:

<link rel="login" href="/auth/verify">
<link rel="logout" href="/auth/logout">

When the browser sees a login tag it could offer login chrome and POST the assertion, remembering the logout URL for later. Single-page apps and sites wanting fancier behavior could still hook into navigator.id.

I see several immediate advantages:

• Browsers would be aware of Persona support declaratively, without needing to wait for the site to announce it. (I thought this was the plan from the start, based on various Firefox UI mockups, but with the current API I don't see how it's possible.)
• Building Persona support into "dumb" clients like curl would be considerably easier.
• I wouldn't need to whitelist sites just to have a (possibly throwaway) account on them. :)

The most obvious drawback is that opt-in fallback mechanisms are easily overlooked. But offered as a simple default, it would give anyone password-less login without writing a line of JS, and might be easier to reason about for sites with existing traditional auth who already have a logout endpoint, flash messages, etc.

Back in the present: the persona.org shim could detect such <link> tags and do the navigator.id dance itself, though that leaves the problem of what replaces browser chrome. Which brings this full circle; a site could implement full login with only:

<a rel="login" href="https://example.com/auth/verify"><img alt="Sign in!" src="signin.png"></a>

• /auth/verify would redirect into the persona.org redirect-flow on GET, passing along the same URL, which persona.org would ultimately POST an assertion to. persona.org would still need to be able to run JavaScript, but the site being logged into would not, and the appropriate flow would happen naturally depending on whether the user has JS enabled. If nothing else, a persona.org "you need JS" error page is a much better experience for NoScript users than a login button that simply does nothing.
• Implementing browsers could interpret using <a> instead of <link> as "don't offer login chrome until this is clicked".
• Any fancy navigator.id behavior could still preventDefault() and do whatever else it wanted instead.
• The login link would become a logout link (or, more likely, form) for a signed-in user, and the browser/shim would detect the rel="logout" and act appropriately.

No idea how feasible this is, especially this late in the game, but I'd feel much more comfortable using Persona if it defaulted to a declarative approach like this.

[eevee]

ping :) this might perhaps belong in a new ticket, but the context here seems valuable.

[seanmonstar]

@eevee sorry about the lack of response. I haven't ignored this. I've been thinking if it would make things better, or introduce other problems.

The thing is, all the features must always be possible from JavaScript, using navigator.id. So, adding rel links might be a convenience to some sites. Others though, would get no use, and it introduces another code path to make sure behaves just as the JavaScript path.

[charmander]

As long as Persona requires JavaScript, some people won’t use it, myself included. It’s a little more than just a convenience.

[eevee]

I'm actually running into the problem right now of needing login for a fairly mundane website. I really like the ideas behind Persona, but I can't justify making a bunch of static text and old-school HTML forms inaccessible without JS support.

[seanmonstar]

@eevee fair enough. I'll continue to think about this. Can't promise what I'll think of though :)

[callahad]

Added this to our feature request backlog as mozilla/persona-roadmap#70

[seanmonstar]

@eevee @charmander i've done some initial work on this, and linked the Pull Request to this issue. join the discussion (if you want) over here: https://groups.google.com/d/topic/mozilla.dev.identity/12PW2Z-YPps/discussion