Universal Login Button

Considering the existence of a community around the idea of a Universal Edit Button already existing I was quite surprised to see that no-one has thought of the idea of a rel=login for a Universal Login Button just like the rel=edit that Universal Edit Button uses (at least as far as I can see through search engines).

For the record, I'm Daniel Friesen and my website and OpenID is http://daniel.friesen.name.

There's been a long history of trying to improve logins.

OpenID uses tags to allow users to delegate OpenID and allow them to use their own homepage url as a login. OpenSearch uses <link> tags to allow browsers so add search engines into their search bar. Universal Edit Button uses <link> tags to allow the browser to place an edit button into the browser chrome.

So I'm quite surprised that no-one has come up with the idea of a <link rel=login to allow browsers to make it easy to find the login page.

Also, considering html5's pile of new elements like progress, meter, and so on, and it's form input types like number, date, time, and especially type=search, as well as the already existing type=password (of course that's there for a different reason) I'm also surprised that html5 also hasn't added something like type=login or at least type=username to make it plain and simple for browsers to know what fields to use when providing password remembering and filling instead of guessing. Because browsers have to make guesses like that, we end up with strange things like browsers trying to fill passwords into registration and password change forms. Which also leads to fun bugs like errors when a user tries to save their settings and because the password field is filled in the software thinks the user is also trying to change their password, and it returns an error to them saying they can't change their password to a blank one (at least in sane systems that don't allow you to use blank passwords).

So here's my ideas for a rel=login and also a way to improve web developer's way of giving hints to the browser to help it provide a more reliable

rel=login

As with rel=edit the user agent should look for a <link> tag in the header with a rel=login in it.

If the <link> tag has no type= attribute or the type= matches a mime type which the browser considers to be a render-able mime type (ie: HTML or XHTML mime types)

<!-- These two should be considered equivalent -->
<link rel=login href="/login.php?returnto=...">
<link rel=login type="text/html" href="login.php?returnto=...">

If the <link> contains a type= which the user agent cannot understand it should ignore it.

Additionally there is potential for other mime types to be used for special cases.

<link rel=login type="application/x-openid" href="/login.php?returnto=...">

This should probably be considered an OpenID specific login and the user agent should consider displaying a "Login with OpenID" with the OpenID logo instead of the logo used for normal Universal Login.

If there are multiple <link> tags which the user agent understands it should probably consider either displaying multiple icons or just displaying the logo used for universal login and on hover displaying a nice rounded box below it extending out from it listing the different types of login.

There are a few other small ideas. Such as perhaps a title= inside the <link> should be able to control a tooltip on the universal login button or the row it's displayed.

And hreflang could be used in a way that the login text will be displayed in another languages (ie: Even if your site is in English you could have separate "Login" and "Ingresa" login rows. This way a Spanish user can click a login link on your English homepage and get a login ui in Spanish. This would be especially useful on a multilingual site where it might not be that easy to make out where the login link is, or any way to get the page in Spanish. It's much easier to see something in your browser chrome than is is to scan a page in a foreign language for a way to read it in your language.

The media attribute could even be used. Say, if a <link> were found on the page using the same media query you use to target small devices like iPhones your iPhone could decide to make that the primary login link considering it a link to a login page targeted specifically at small devices. Other desktop user agents could ignore these <link> tags since the media does not match.

Originally the idea for mimetype based logins came from the idea of a one-click OpenID login. ie: The href= describes a returnto instead of a login page and clicking on it brings you directly to your openid provider. But then I thought that with the form stuff required for OpenID that might not actually work.

However that may have a potential to work with some things like facebook connect, though I can't say for certain since I never looked at it myself.

I did have the other idea of instead just allowing multiple rel=login links with titles controlled by title= instead of the mime type based things like OpenID, which would allow things like OpenID, Facebook connect, Twitter, Google, etc... to be separately defined without a need for login specific code to be added to the user agent. However I was unable to come up with an idea on how the logo for that entry could be controlled, which is important for things like "Login with OpenID" and "Login with Facebook Connect" to work. Other than something like a not so nice extra icon= attribute that wouldn't allow mimetype to work.

It might even be desire-able to allow javascript: urls to work allowing things like Facebook connect to use the normal in-page ajax based login.

To finish up in addition to login, logout should probably be made possible to.

<link rel=logout href="/logout.php">

rel=login and rel=logout should not appear at the same time on a page. rel=login should only be present when logged out, and rel=logout should only be present when logged in. This makes it possible for the browser to display indications on whether you are logged in or out and potentially change the ui in small ways to help make this more noticeable.

Form changes

In addition to the idea of a universal login button there is another small issue or two. Firstly the issue I noted up in the intro about how browsers try to autofill passwords into registration and change password forms creating some not-so fun, or at least just not so elegant annoyances.

For those issues I would recommend the addition of a new addition to the input field. Originally I thought of <input type=login> and then <input type=username>. My first thought for type=login instead of type=username was because of other login types such as OpenID, username didn't fit. Then I thought that things like OpenID didn't fit in with passwords so type=username would actually be best so that type=username and type=password could pair up. At this point I have a third idea and am a little mixed in between it and type=username.

The idea is to use type=login along with an additional form attribute, this form attribute would determine what kind of login type is applicable to this form field. The content of that attribute could possibly be a mime type. The assumption that any field using type=login without a mimetype should be a username to be paired with a password should be made. And we could probably adopt something like application/x-username to signify specifically that's what it is. Then other auth types could use values like application/x-openid to point to OpenID logins and browsers could be made smart enough to pre-fill information like OpenID login names into these forms even on the first time someone has arrived on the site.

Password memorisation and realms

However there is another issue. Remember those things called cookies? The issue has nothing to do with cookies, but rather, password memory features appear to have a bit of a flaw in them where they lack the same kind of domain/path restriction feature that cookies do.

For example, on Wikia and all the wiki which they host my MediaWiki login is applicable to all the wiki there. If I login on naruto.wikia.com and head over to animanga.wikia.com I will still be logged in. However if I login to naruto.wikia.com and have the browser remember my password, then I logout and head over to animanga.wikia.com, it will not fill in my password, despite the fact that they both use the same auth system.

Why is this? My assumption is that browsers associate passwords based on the action= in the form and as a result because the two installations sit on two different domains and point to their own respective login pages so that the user is not pulled off the site when they login and cookies can be set in a single http request the browser associates these two login forms with different passwords. And this is a fair bit of annoyance because I use a large number of wiki there, and a lot of the time I land on different wiki at times when I have to log back in.

As a side effect to this as well if a site has a simple login form up top, and a full featured login page, or the site uses returnto= urls and embeds the returnto inside of an input in the form (which would result in the returnto disappearing from the addressbar which may be an unwanted behaviour in the opinion of the developer) then two different login locations may not respond properly to autofilling in passwords on the very same site.

So for this reason I suggest some additions to the <form> which could make it possible for web applications to control what address browser's built in password memory features use when storing passwords so that forms can be filled reliably.

If a domain= and/or path= is present in the <form> tag they should be used instead of the action= attribute. If only one is defined then it should be implied the same way that cookies do (ie: domain omitted = current domain, path omitted = /). Or perhaps we should just require both of them.

Now for the security conscious people that will probably think of pointing out that "Allowing html authors to control the domain and path which password memory features use for associating passwords to sites could introduce a potential for websites to attack other sites by using a domain and path which catches passwords from a different site and allows them to use JavaScript to steal the password which the browser automatically fills in".

My proposal for the domain and path control of password memory features matches that of cookies. ie: The domain and path should be restricted in the very same way that cookies are. Which includes a number of restrictions such as:

If any one of these is violated the domain= and path= become invalid and the browser falls back to using the same method it usually uses to keep passwords safe.

Additionally I believe that the domain and path should probably match exactly. ie: If the login form defines the path as /mysite/, then passwords defined for / should not be available (unlike cookies where cookies set at / are available to /mysite/). Though, perhaps that's a needless restriction. Right now it's just an idea, this site is just my ideas at the start of this I don't really think any of this should be implemented until a lot of people actually get together and discuss all the possible security implications and decide how to deal with them.

So because of those restrictions, the only case where a password can be stolen should be in a limited subset of the case where a site can already look at the other site's cookies and steal the user's session (ie: You're already vulnerable to session sealing attacks). Theoretically the password memory feature is possible to secure in a way that cookies can't be secured in. Instead of making your domain/path for password memory match the example.com/ that you use in cookies, use something like example.com/path/to/my/login/form. With cookies you need to make the cookie available to the entire site, however with password memory, you only need to make the password available to the login form.

So pretty much the idea is that a form could be started like:

<form action="/login.php?returnto=..." domain="example.com" path="/">
...

And if the form is located on example.com or a subdomain of it the password memory feature will use example.com/ instead of an absolute form of /login.php?returnto=... (which would have the side effect of making that password reminder not work if you came from a different page).

comments powered by Disqus